Publications

A key collaborative hub for many software development projects is the bug report repository. Although its use can improve the software development process in a number of ways, reports added to the repository need to be triaged. A triager determines if a report is meaningful. Meaningful reports are then organized for integration into the project's development process. To assist triagers with their work, this article presents a machine learning approach to create recommenders that assist with a variety of decisions aimed at streamlining the development process. The recommenders created with this approach are accurate; for instance, recommenders for which developer to assign a report that we have created using this approach have a precision between 70% and 98% over five open source projects. As the configuration of a recommender for a particular project can require substantial effort and be time consuming, we also present an approach to assist the configuration of such recommenders that significantly lowers the cost of putting a recommender in place for a project. We show that recommenders for which developer should fix a bug can be quickly configured with this approach and that the configured recommenders are within 15% precision of hand-tuned developer recommenders.

Finding relevant information within the vast amount of information exchanged via feeds is difficult. Previous research into this problem has largely focused on recommending relevant information based on topicality. By not considering individual and situational factors these approaches fall short. Through a formative, interview-based study, we explored how five software developers determined relevancy of items in two kinds of project news feeds. We identified four factors that the developers used to help determine relevancy and found that placement of items in source code and team contexts can ease the determination of relevancy.

Implementing software development tools as integrated development environment (IDE) plugins gives tools direct access to a range of useful representations of the program being created and can improve programmer efficiency. These benefits must be weighed against the effort to integrate the tool into the IDE, effort which may need to be repeated for each IDE targeted. In this paper, we introduce Fishtail, a prototype plugin for the Eclipse IDE, which assists programmers in discovering code examples and documentation on the web relevant to their current task. Fishtail uses a detailed history of programmer interactions with the source code to automatically determine relevant web resources. We describe the key factors that make it attractive to implement Fishtail as a plugin, and the requirements Fishtail imposes on the plugin/IDE interface. To reach a broader user base and understand how well our tool supports different programming styles and IDE architectures, we have recently begun investigating how to make a version of Fishtail available in the Visual Studio IDE. We outline some of the challenges we face in trying to reuse code from the original Eclipse plugin.

The reflexion model technique supports structural conformance checking of software systems. The scalability of the technique is limited by the requirement for developers to provide a mapping between implementation entities and high-level modules. Such mapping is usually based on regular expressions, and it must also be updated as the system evolves. Automated mapping techniques exist but are solely based on structural dependencies. In this paper, we introduce an automated mapping technique for reflexion models based on information retrieval techniques. It makes use of source code vocabulary and their similarity to the vocabulary of high-level modules. Two case studies conducted across four systems show that the nature of the module view influences which technique performs best. Results also show that combining both mapping techniques into a two step-mapping algorithm generally increases recall, while keeping precision similar to the best approach used in isolation.

Programming language innovation has been hindered by the difficulty of making changes to existing languages. A key source of difficulty is the tyrannical nature of existing approaches to realizing languages -- adding a new language construct means that any tool, document or programmer that works with the language must be prepared to deal with that construct. A registration-based approach makes it possible to define language constructs that are not tyrannical. They are instead transient -- the program appears to be written using the constructs only so long as a given programmer wants to see it that way. This approach may have the potential to greatly facilitate programming language innovation.

Each day, a software developer needs to answer a variety of questions that require the integration of different kinds of project information. Currently, answering these questions, such as "What have my co-workers been doing?",

The non-local nature of advice applicability in AspectJ means that in many implementations small changes to aspects can require much of the program code to be scanned and possibly rewritten. This can slow down application startup, including the edit-compile-debug development cycle. Late binding of advice has been suggested to improve the situation, at the potential cost of runtime performance. We propose and evaluate two virtual machine (VM) internal late binding approaches, that operate at whole-class and whole-method granularity. Our evaluation shows that in VMs that allow bytecode mutation the preferred approach is to scan and rewrite methods the first time they are executed. In other VMs, whole-class scanning and rewriting at load time performs better. A separate interpreter based approach has startup performance similar to that of the whole-class approach; but micro-benchmarks suggest the latter out-performs the former over time.

Many recommendation systems have been built to aid software developers. Few have been evaluated using human-based evaluation strategies. In studying situations where recommendation systems have been used or might be used, we have observed that issues related to trust are important to a developer's acceptance of recommendations. In this position paper, we outline the trust issues that we have identified and suggest some mechanisms for promoting trust in recommendation systems aimed at software developers.

Code smells are characteristics of software that indicate that code may have a design problem. Code smells have been proposed as a way for programmers to recognize the need for restructuring their software. Because code smells can go unnoticed while programmers are working, tools called smell detectors have been developed to alert programmers to the presence of smells in their code, and to help them understand the cause of those smells. In this paper, we propose a novel smell detector called Stench Blossom that provides an interactive ambient visualization designed to first give programmers a quick, high-level overview of the smells in their code, and then, if they wish, to help in understanding the sources of those code smells. We also describe a laboratory experiment with 12 programmers that tests several hypotheses about our tool. Our findings suggest that programmers can use our tool effectively to identify smells and to make refactoring judgements. This is partly because the tool serves as a memory aid, and partly because it is more reliable and easier to use than heuristics for analyzing smells.

Many software artifacts are created, maintained and evolved as part of a software development project. As software developers work on a project, they interact with existing project artifacts, performing such activities as reading previously filed bug reports in search of duplicate reports. These activities often require a developer to peruse a substantial amount of text. In this paper, we investigate whether it is possible to summarize software artifacts automatically and effectively so that developers could consult smaller summaries instead of entire artifacts. To provide focus to our investigation, we consider the generation of summaries for bug reports. We found that existing conversation-based generators can produce better results than random generators and that a generator trained specifically on bug reports can perform statistically better than existing conversation-based generators. We demonstrate that humans also find these generated summaries reasonable indicating that summaries might be used effectively for many tasks.

Desktop client applications interact with both local and remote resources. This is both a benefit in terms of the rich features desktop clients can provide, but also a security risk. Due to their high connectivity, desktop clients can leave a user's machine vulnerable to viruses, malicious plug-ins, and scripts. Aspect-Oriented Software Development can be used to address security concerns in software in a modular fashion. However, most existing research focuses on the protection of server-side resources. In this paper we introduce an aspect-oriented mechanism, Authority Aspects, to enforce the Principle of Least Privilege on desktop clients. This helps to ensure that legitimate resource access is allowed and illegitimate access is blocked. We present a case study applying our approach on two desktop applications: an RSS feed aggregator and a Web browser.

Traditionally, the composition of Web services to create mashups has been achieved by using an application server as a mediator between a client browser and services. To avoid this bottleneck, mashups are sometimes implemented so that Web service composition takes place directly from the end user’s browser. Creating such implementations is difficult because developers must manage the separation of software into various distributable pieces, in different languages, and coordinate their communication. In this paper we describe a middleware for managing Web service mashups in a disciplined, and flexible way. We build upon the established abstraction of XML pipelines, but describe a new approach for selectively partitioning pipeline components between a browser client and application server. We provide a performance evaluation for a common mashup application scenario.

Programmers seek to answer questions as they investigate the functioning of a software system, such as "which execution path is being taken in this case?" Programmers attempt to answer these questions, which we call conceptual queries, using a variety of tools. Each type of tool typically highlights one kind of information about the system, such as static structural information or control-flow information. Unfortunately for the programmer, the tools seldom directly answer the programmer's conceptual queries. Instead, the programmer must piece together results from different tools to determine an answer to the initial query. At best, this process is time consuming and at worst, this process can lead to data overload and disorientation.

One difficulty in software maintenance is that the relationship between observed program behavior and source code is not always clear. In this paper we are concerned specifically with the maintenance of graphical user interfaces (GUIs). User interface code can crosscut the decomposition of applications making GUIs hard to maintain. A popular approach to develop and maintain GUIs is to use "What you see is what you get" editors. They allow developers to work directly with a graphical design view instead of scattered source elements. Unfortunately GUI editors are limited by their ability to statically reconstruct dynamic collaborations between objects. In this paper we investigate the combination of a hybrid dynamic and static approach to allow for view-based maintenance of GUIs. Dynamic analysis reconstructs object relationships, providing a concrete context in which maintenance can be performed. Static checking restricts that only changes in the design view which can meaningfully be translated back to source are allowed. We implemented a prototype IDE plug-in and evaluate our approach by applying it to five open source projects.

Programmers spend a significant amount of time navigating code. However, few details are known about how this time is spent. To investigate this time, we performed a study of professional programmers performing programming tasks. We found that these professionals frequently needed to follow execution paths in the code, but that they often made faulty assumptions about which code had executed, impeding their progress. Earlier work on software reconnaissance has addressed this problem, but has focused on whether the technique could provide the correct information to a programmer, not on whether the technique reduces or improves navigation. We built a tool, called Tripoli, that provides an approximation to software reconnaissance via differential code coverage and reran a subset of the initial study. We found that Tripoli had a positive effect on code navigation: less experienced programmers with Tripoli were often more successful in less time than experienced programmers without.

In this paper, we present algorithms that compute two kinds of information that can help AspectJ developers diagnose and fix potential problems with their pointcuts. First, we present an algorithm to compute almost matched joinpoints. Second, we present algorithms to compute explanations of why a pointcut does not match (or does match) a specific joinpoint. We implemented two tools using these algorithms. The first is an offline tool that analyzes a code base and produces a comprehensive report about the pointcuts in the code. Using this tool, we were able to find several real problems in existing, medium-sized AspectJ code bases. The second tool is an Eclipse plug-in called PointcutDoctor. PointcutDoctor is a natural extension of AJDT that provides developers easy access to the same information from within their already familiar development environment.

Crosscutting concerns degrade software quality. Before we can modularize the crosscutting concerns in our programs to increase software quality, we must first be able to find them. Unfortunately, accurately locating the code related to a concern is difficult, and without proper metrics, determining how much the concern is crosscutting is impossible. We propose a systematic methodology for identifying which code is related to which concern, and a suite of metrics for quantifying the amount of crosscutting code. Our concern identification and assignment guidelines resolve some of the ambiguity issues encountered by other researchers. We applied this approach to systematically identify all the requirement concerns in a 13,531 line program. We found that 95\% of the concerns were crosscutting - indicating a significant potential for improving modularity - and that our metrics were better able to determine which concerns would benefit the most from reengineering.

The practice of software development can likely be improved if an externalized model of each programmer's knowledge of a particular code base is available. Some tools already assume a useful form of such a model can be created from data collected during development, such as expertise recommenders that use information about who has changed each file to suggest who might answer questions about particular parts of a system. In this paper, we report on an empirical study that investigates whether a programmer's activity can be used to build a model of what a programmer knows about a code base. In this study, nineteen professional Java programmers completed a series of questionnaires about the code on which they were working. These questionnaires were generated automatically and asked about program elements a programmer had worked with frequently and recently and ones that he had not. We found that a degree of interest model based on this frequency and recency of interaction can often indicate the parts of the code base for which the programmer has knowledge. We also determined a number of factors that may be used to improve the model, such as authorship of program elements, the role of elements, and the task being performed.

Context plays a large role in our perspective on the world around us--people see things differently depending on background, role, task at hand, and many other variables.

Open source development projects typically support an open bug repository to which both developers and users can report bugs. The reports that appear in this repository must be triaged to determine if the report is one which requires attention and if it is, which developer will be assigned the responsibility of resolving the report. Large open source developments are burdened by the rate at which new bug reports appear in the bug repository. In this paper, we present a semi-automated approach intended to ease one part of this process, the assignment of reports to a developer. Our approach applies a machine learning algorithm to the open bug repository to learn the kinds of reports each developer resolves. When a new report arrives, the classifier produced by the machine learning technique suggests a small number of developers suitable to resolve the report. With this approach, we have reached precision levels of 57\% and 64\% on the Eclipse and Firefox development projects respectively. We have also applied our approach to the gcc open source development with less positive results. We describe the conditions under which the approach is applicable and also report on the lessons we learned about applying machine learning to repositories used in open source development.

Modern IDEs have an open-ended plugin architecture to allow customizability. However, developing a plugin is costly in terms of effort and expertise required by the customizer. We present a two-pronged approach that allows for open-ended customizations while keeping the customization cost low. First, we explicitly limit the portion of the design space targeted by the configuration mechanism. This reduces customization cost by simplifying the configuration interface. Second, we use a declarative programming language as our configuration language. This facilitates open-ended specification of behavior without burdening the user with operational details. Keywords: integrated development environment, program database, domain-specific language, logic programming.

How can the ultra large systems (ULS) of the future be built if they will have the complexity of trillions of lines of code, maintain continuous 24x7 operations with no downtime, and live in a hostile environment with unpredictably changing requirements? This panel will discuss and debate the challenges posed by ultra large systems in terms of their design, growth, deployment and dynamics.

In the web services environment software development can involve writing both object-oriented programs and XML transformations. This can be seen in the popular Web Services architecture. In this architecture, crosscutting concerns are often manifest as transformations on XML messages; encrypting messages, adapting between schemas types or adding extra-functional elements such as transaction contexts can be seen as prime examples. Some existing middleware platforms provide support for Handlers where crosscutting message transformation concerns can be addressed. Although handlers localize some concerns, they do not support the sound software-engineering principle of "programming to an interface". This prevents a clean mapping from design to implementation and inhibits useful static checking which could take advantage of a well specified interface. To address this and similar design challenges, we have developed Doxpects, which solve many problems with the existing handler approach to implementing these new crosscutting concerns. We describe an AOP abstraction called the content-based pointcut which integrates support for XML transformation to enable implementation of crosscutting concerns with good modularity properties. We present examples based on XML encryption and service interoperability implemented on top of the Apache Axis Web Services middleware.

Most open source software development projects include an open bug repository---one to which users of the software can gain full access---that is used to report and track problems with, and potential enhancements to, the software system. There are several potential advantages to the use of an open bug repository: more problems with the system might be identified because of the relative ease of reporting bugs, more problems might be fixed because more developers might engage in problem solving, and developers and users can engage in focused conversations about the bugs, allowing users input into the direction of the system. However, there are also some potential disadvantages such as the possibility that developers must process irrelevant bugs that reduce their productivity. Despite the rise in use of open bug repositories, there is little data about what is stored inside these repositories and how they are used. In this paper, we provide an initial characterization of two open bug repositories from the Eclipse and Firefox projects, describe the duplicate bug and bug triage problems that arise with these open bug repositories, and discuss how we are applying machine learning technology to help automate these processes.

Aspect-oriented software development (AOSD) has a lot of interest in the research community. It has also found early adopters in application development and middleware. This panel discusses the potential expansion and use of AOP into mainstream software development.This question is not just directed to the aspect research community, but also to practicing software development teams and organizations. The panel will explore the appropriate position and awareness of aspect-orientation amidst other advances in software engineering; how to prepare organizations for adoption; and what additional research and development is necessary. The panel discussion will help the OO community to understand the appropriate use of aspect-orientation. It will also highlight areas where additional efforts by AOSD researchers and professionals are required.

Middleware is often built using a layered architectural style. Layered design provides good separation of the different concerns of middleware, such as communication, marshaling, request dispatching, thread management, etc. Layered architecture helps in the development and evolution of the middleware. It also provides tactical side-benefits: layers provide convenient protection boundaries for enforcing security policies. However, the benefits of this layered structure come at a cost. Layered designs can hinder performance-related optimizations, and actually make it more difficult to adapt systems to conveniently address late-bound requirements such as dependability, access control, virus protection, and so on. We present some examples of this issue, and outline a new approach, under investigation at UC Davis, which includes ideas in middleware, architectures, and programming models.

We describe CodeQuest, a system for querying source code. It combines two previous proposals, namely the use of logic programming and database system. Experiments (on projects ranging from 3KSLOC to 1300KSLOC) confirm that for this application, a query language based on DataLog strikes the right balance between expressiveness and scalability.

Using the application programming interfaces (API) of large software systems requires developers to understand details about the interfaces that are often not explicitly defined. However, documentation about the API is often incomplete or out of date. Existing systems that make use of the API provide a form of implicit information on how to use that code. Manually searching through existing projects to find relevant source code is tedious and time consuming. We have created the Strathcona Example.Recommendation Tool to assist developers in finding relevant fragments of code, or examples, of an API's use. These examples can be used by developers to provide insight on how they are supposed to interact with the API.

Even when working on a well-modularized software system, programmers tend to spend more time navigating the code than working with it. This phenomenon arises because it is impossible to modularize the code for all tasks that occur over the lifetime of a system. We describe the use of a degree-of-interest (DOI) model to capture the task context of program elements scattered across a code base. The Mylar tool that we built encodes the DOI of program elements by monitoring the programmer's activity, and displays the encoded DOI model in views of Java and AspectJ programs. We also present the results of a preliminary diary study in which professional programmers used Mylar for their daily work on enterprise-scale Java systems.

Aspects cut new interfaces through the primary decomposition of a system. This implies that in the presence of aspects, the complete interface of a module can only be determined once the complete configuration of modules in the system is known. While this may seem anti-modular, it is an inherent property of crosscutting concerns, and using aspect-oriented programming enables modular reasoning in the presence of such concerns.

In this position paper, we propose the notion of just-in-time concern modeling. As some concerns emerge late in the software life cycle and can be ephemeral, we argue that mechanisms should be available to capture descriptions of concerns as they emerge or become relevant. Based on our experience with the FEAT concern modeling and analysis tool, we highlight the essential characteristics, benefits, and pitfalls of just-in-time concern modeling at the source code level.

We propose bottom-up support for modeling crosscutting structure in UML by adding a simple join point model to the meta-model. This supports built-in crosscutting modeling constructs such as sequence diagrams. It also facilitates adding new kinds of crosscutting modeling constructs such as role bindings, inter-type declarations, and advice. A simple weaver produces a uniform representation of the crosscutting structure, which can then be displayed or analyzed in a variety of ways.

Sociological and technical difficulties, such as a lack of informal encounters, can make it difficult for new members of noncollocated software development teams to learn from their more experienced colleagues. To address this situation, we have developed a tool, named Hipikat that provides developers with efficient and effective access to the group memory for a software development project that is implicitly formed by all of the artifacts produced during the development. This project memory is built automatically with little or no change to existing work practices. After describing the Hipikat tool, we present two studies investigating Hipikat's usefulness in software modification tasks. One study evaluated the usefulness of Hipikat's recommendations on a sample of 20 modification tasks performed on the Eclipse Java IDE during the development of release 2.1 of the Eclipse software. We describe the study, present quantitative measures of Hipikat's performance, and describe in detail three cases that illustrate a range of issues that we have identified in the results. In the other study, we evaluated whether software developers who are new to a project can benefit from the artifacts that Hipikat recommends from the project memory. We describe the study, present qualitative observations, and suggest implications of using project memory as a learning aid for project newcomers.

A typical IDE based exploration of an OOP system will often involve multiple searches through class hierarchies, field accesses, method calls, regular expression matches and more. Developers who must follow connections between these disconnected views may find great difficulty in combining the capabilities of each view and may as well suffer significant disorientation due to loss of context while switching. toolname is a flexible, query-based source code browser that alleviates this disorientation by allowing the user to explore the various types of structural relationships between elements of the code without the distraction of switching tools. Using toolname, a developer can define his or her own top-level browsers on-the-fly by formulating logic queries and running them against the source code. Elements in the tree can then be queried individually in the same manner, allowing further exploration of the complex web of relationships that exist between scattered elements of code.

Prior to performing a software change task, developers must discover and understand the subset of the system relevant to the task. Since the behavior exhibited by individual developers when investigating a software system is influenced by intuition, experience, and skill, there is often significant variability in developer effectiveness. To understand the factors that contribute to effective program investigation behavior, we conducted a study of five developers performing a change task on a medium-size open source system. We isolated the factors related to effective program investigation behavior by performing a detailed qualitative analysis of the program investigation behavior of successful and unsuccessful developers. We report on these factors as a set of detailed observations, such as evidence of the phenomenon of inattention blindness by developers skimming source code. In general, our results support the intuitive notion that a methodical and structured approach to program investigation is the most effective.

A characteristic of aspect-oriented programming, as embodied in Aspect J, is the use of advice and point cuts to define behavior that crosscuts the structure of the rest of the code. The events during execution at which advice may execute are called join points. A pointcut is a set of join points. An advice is an action to be taken at the join points in a particular pointcut. In this model of aspect-oriented programming, join points are dynamic in that they refer to events during the flow of execution of the program.We give a denotational semantics for a minilanguage that embodies the key features of dynamic join points, pointcuts, and advice. This is the first semantics for aspect-oriented programming that handles dynamic join points and recursive procedures. It is intended as a baseline semantics against which future correctness results may be measured.

The lack of lightweight communication channels and other technical and sociological difficulties make it hard for new members of a non-collocated software development team to learn effectively from their more experienced colleagues while they are coming up-to-speed on a project. To address this situation, we have developed a tool, named Hipikat, that provides developers with efficient and effective access to the group memory for a software development project that is implicitly formed by all of the artifacts produced during the development. This \textlessi\textgreaterproject memory\textless/i\textgreater is built automatically with little or no change to existing work practices. We report an exploratory case study evaluating whether software developers who are new to a project can benefit from the artifacts that Hipikat recommends from the project memory. To assess the appropriateness of the recommendations, we investigated when and how developers queried the project memory, how the evaluated the recommended artifacts, and the process by which they utilized the artifacts. We found that newcomers did use the recommendations and their final solutions exploited the recommended artifacts, although most of the Hipikat queries came in the early stages of a change task. We describe the case study, present qualitative observations, and suggest implications of using project memory as a learning aid for project newcomers.

A developer attempting to evolve a system in which design patterns have been applied can benefit from knowing which code implements which design pattern. For instance, the developer may be able to understand the purpose, or to assess the flexibility of the code, more quickly. The degree to which the developer benefits depends upon their understanding of the pattern. Achieving an in-depth understanding of even a simple pattern can be difficult as pattern descriptions span several pages of text, and discuss interrelated design concepts and choices. To enable a developer to effectively trace the design goals associated with a pattern to and from source, we have developed the Design Pattern Rationale Graph (DPRG) approach and associated tool. A DPRG makes explicit the relationships between design concepts in a design pattern, provides a graphical representation of the design pattern text, and supports the linking of those concepts to implementing code. In this paper, we introduce the DPRG approach and tool, and present case studies to show that a DPRG can, at low-cost, help a developer identify design goals in a pattern, and can improve a developer's confidence about how those goals are realized in a code base.

The FreeBSD operating system more than doubled in size between version 2 and version 4. Many changes to primary modularity are easy to spot at a high-leveL For example, new device drivers account for 38\% of the growth. Not surprisingly, changes to crosscutting concerns are more difficult to track. In order to better understand how an aspect-oriented implementation would have fared during this evolution, we introduced several aspects to version 2 code, and then rolled them forward into their subsequent incarnations in versions 3 and 4 respectively. This paper describes the impact evolution had on these concerns, and provides a comparative analysis of the changes required to evolve the tangled versus aspect-oriented implementations.Our results show that for the concerns we chose, the aspect-oriented implementation facilitated evolution in four key ways: (1) changes were better localized, (2) configurability was more explicit, (3) redundancy was reduced, and (4) extensibility aligned with an aspect was more modular. Additionally, we found that the aspect-oriented implementation had negligible impact on performance.

Current refactorings for restructuring existing software systems preserve the behavior of the software. Aspect-oriented programming constructs make existing refactorings more complex, and introduce the potential for new kinds of refactorings that target entire concerns. In many cases, behaviour preservation may be neither possible nor desirable. In this position paper, we propose an approach to refactoring aspects into a system that actively involves a developer in a dialogue with the refactoring tool. We are exploring this approach by developing two Eclipse plug-ins: one which bases the refactoring on descriptions of a concern in the code; the other which bases the refactoring on a target aspect structure.

In any programming system the environment in which a program is constructed is tightly bound to the format of the data used to represent that program. As software development environments are becoming more sophisticated, there is a growing need to get richer representations of programs that allow programs to be treated at a much higher level of abstraction than as sequences of characters in source files.In this paper we explore the use of a database representation as a medium for representing and manipulating programs. We report on the work we did on two different Eclipse plugins exemplifying the potential advantages of such a representation. The first plugin explores the use of a database representation to store programs written in a traditional programming language (Java). The second plugin is part of a research effort to try to define a programming language directly in terms of a database representation.

This paper presents a semantics-based compilation model for an aspect-oriented programming language based on its operational semantics. Using partial evaluation, the model can explain several issues in compilation processes, including how to find places in program text to insert aspect code and how to remove unnecessary run-time checks. It also illustrates optimization of calling-context sensitive pointcuts (cflow), implemented in real compilers.

This paper reports on the results of the workshop on Declarative Meta Programming to Support Software Development in Edinburgh on September 23, 2002. It enumerates the presentations made, classifies the contributions and lists the main results of the discussions held at the workshop. As such it provides the context for future workshops around this topic.

Exception-handling mechanisms in modern programming languages provide a means to help software developers build robust applications by separating the normal control flow of a program from the control flow of the program under exceptional situations. Separating the exceptional structure from the code associated with normal operations bears some consequences. One consequence is that developers wishing to improve the robustness of a program must figure out which exceptions, if any, can flow to a point in the program. Unfortunately, in large programs, this exceptional control flow can be difficult, if not impossible, to determine.In this article, we present a model that encapsulates the minimal concepts necessary for a developer to determine exception flow for object-oriented languages that define exceptions as objects. Using these concepts, we describe why exception-flow information is needed to build and evolve robust programs. We then describe Jex, a static analysis tool we have developed to provide exception-flow information for Java systems based on this model. The Jex tool provides a view of the actual exception types that might arise at different program points and of the handlers that are present. Use of this tool on a collection of Java library and application source code demonstrates that the approach can be helpful to support both local and global improvements to the exception-handling structure of a system.

Code is modularized, for many reasons, including making it easier to understand, change, and verify. Aspect-oriented programming approaches extend the kind of code that can be modularized, enabling the modularization of crosscutting code. We conducted an inquisitive study to better understand the kinds of crosscutting code that software developers encounter and to better understand how the developers manage this code. We tracked eight participants: four from industry and four from academia. Each participant was currently evolving a non-trivial software system. We interviewed these participants three times about crosscutting concerns they had encountered and the strategies they used to deal with the concerns. We found that crosscutting concerns tended to emerge as obstacles that the developer had to consider to make the desired change. The strategy used by the developer to manage the concern depended on the form of the obstacle code. The results of this study provide empirical evidence to support the problems identified by the aspect-oriented programming community, and provide a basis on which to further assess aspect-oriented programming.

Many design concepts can be expressed only indirectly in source code. When this occurs, a single concept at design results in a verbose amount of code that is scattered across the system structure. In this paper, we present explicit programming, an approach that enables a developer to introduce new vocabulary into the source to capture a design concept explicitly. An introduced vocabulary item modularizes the implementation details associated with a design concept, reducing the scattering of code needed to express the concept. The vocabulary item appears in the code where the concept is needed; uses of the vocabulary may thus remain distributed through the code. We believe explicit programming provides a useful engineering point, balancing modularization and separation in (at least) two cases. First, when a design concept is tightly coupled with particular constructs in a program, separation is unlikely to lead to any benefits of reusability or comprehensibility. Second, concepts that emerge as a system evolves can be encapsulated and recorded, paving the way for later separation when conditions warrant it. We introduce ELIDE, a tool that supports explicit programming in Java, and describe several cases showing the utility of the explicit programming approach.

AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements are manifested in terms of better code locality, reusability, composability, and (un)pluggability.The degree of improvement in implementation modularity varies, with the greatest improvement coming when the pattern solution structure involves crosscutting of some form, including one object playing multiple roles, many objects playing one role, or an object playing roles in multiple pattern instances.

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.

Requirements that have a crosscutting impact on software (such as distribution or persistence) present many problems for software development that manifest themselves throughout the lifecycle. Inherent properties of crosscutting requirements, such as scattering (where their support is scattered across multiple classes) and tangling (where their support is tangled with elements supporting other requirements), reduce the reusability, extensibility, and traceability of the affected software artefacts. Scattering and tangling exist both in designs and code and must therefore be addressed in both. To remove scattering and tangling properties, a means to separate the designs and code of crosscutting behaviour into independent models or programs is required. This paper discusses approaches that achieve exactly that in either designs or code, and presents an investigation into a means to maintain this separation of crosscutting behaviour seamlessly across the lifecycle. To achieve this, we work with composition patterns at the design level, AspectJ and Hyper/J at the code level, and investigate a mapping between the two levels. Composition patterns are a means to separate the design of crosscutting requirements in an encapsulated, independent, reusable, and extensible way. AspectJ and Hyper/J are technologies that provide similar levels of separation for Java code. We discuss each approach, and map the constructs from composition patterns to those of AspectJ and Hyper/J. We first illustrate composition patterns with the design of the Observer pattern, and then map that design to the appropriate code. As this is achieved with varying levels of success, the exercise also serves as a case study in using those implementation techniques.

The artifacts constituting a software system often drift apart over time. We have developed the software reflexion model technique to help engineers perform various software engineering tasks by exploiting, rather than removing, the drift between design and implementation. More specifically, the technique helps an engineer compare artifacts by summarizing where one artifact (such as a design) is consistent with and inconsistent with another artifact (such as source). The technique can be applied to help a software engineer evolve a structural mental model of a system to the point that it is “good enough” to be used for reasoning about a task at hand. The software reflexion model technique has been applied to support a variety of tasks, including design conformance, change assessment, and an experimental reengineering of the million-lines-of-code Microsoft Excel product. We provide a formal characterization of the reflexion model technique, discuss practical aspects of the approach, relate experiences of applying the approach and tools, and place the technique into the context of related work

Exception handling mechanisms are intended to help developers build robust systems. Although an exception handling mechanism provides a basis for structuring source code dealing with unusual situations, little information is available to help guide a developer in the appropriate application of the mechanism. In our experience, this lack of guidance leads to complex exception structures. In this paper, we reflect upon our experiences using the Java exception handling mechanism. Based on these experiences, we discuss two issues we believe underlie the difficulties encountered: exceptions are a global design problem, and exception sources are often difficult to predict in advance. We then describe a design approach, based on work by Litke for Ada programs, which we have used to simplify exception structure in existing Java programs.

Information about a software system's execution can help a developer with many tasks, including software testing, performance tuning, and program understanding. In almost all cases, this dynamic information is reported in terms of source-level constructs, such as procedures and methods. For some software engineering tasks, source-level information is not optimal because there is a wide gap between the information presented (i.e., procedures) and the concepts of interest to the software developer (i.e., subsystems). One way to close this gap is to allow developers to investigate the execution information in terms of a higher-level, typically architectural, view. In this paper, we present an encoding technique for dynamic trace information that makes it tractable and efficient to manipulate a trace from a variety of different architecture-level viewpoints. To motivate the need for the encoding technique, we describe two tools that use the technique: a visualization tool and a path query tool. We present the encoding technique to enable the development of additional tools that manipulate dynamic information at a higher-level than source.

The Advanced Teaching and Learning Academic Server (Atlas) is a software system that supports web-based learning. Students can register for courses, and can navigate through personalized views of course material. Atlas has been built according to Sun Microsystem's Java™ Servlet specification using Xerox PARC's aspect-oriented programming support called Aspect™. Since aspect-oriented programming is still in its infancy, little experience with employing this paradigm is currently available. In this paper, we start filling this gap by describing the aspects we used in Atlas and by discussing the effect of aspects on our object-oriented development practices. We describe some rules and policies that we employed to achieve our goals of maintainability and modifiability, and introduce a straightforward notation to express the design of aspects. Although we faced some obstacles along the way, this combination of technology helped us build a fast, well-structured system in a reasonable amount of time.

Determining whether a new software development technique is useful and usable is a challenging taste. Various flavors of empirical study may be used to help with this task, including surveys, case studies, and experiments. Little guidance is available within the software engineering community to help choose among these alternatives when assessing a new and evolving software development technique within some cost bounds. We faced this challenge when assessing a new programming technique called aspect-oriented programming. To assess the technique, we chose to apply both a case study approach and a series of four experiments because we wanted to understand and characterize the kinds of information that each approach might provide. We describe and critique the evaluation methods we employed, and discuss the lessons we have learned. These lessons are applicable to other researchers attempting to assess new programming techniques that are in an early stage of development

Exception handling mechanisms provided by programming languages are intended to ease the difficulty of developing robust software systems. Using these mechanisms, a software developer can describe the exceptional conditions a module might raise, and the response of the module to exceptional conditions that may occur as it is executing. Creating a robust system from such a localized view requires a developer to reason about the flow of exceptions across modules. The use of unchecked exceptions, and in object-oriented languages, subsumption, makes it difficult for a software developer to perform this reasoning manually. In this paper, we describe a tool called Jex that analyzes the flow of exceptions in Java code to produce views of the exception structure. We demonstrate how Jex can help a developer identify program points where exceptions are caught accidentally, where there is an opportunity to add finer-grained recovery code, and where error-handling policies are not being followed.