APIs matter in software development, but determining how to use them can be challenging. Developers often refer to a small set of API usage examples, analyzing the information there to understand and adapt them to their own context. Generalization over many examples may aid in understanding commonalities and differences, reducing information overload while including greater variety. We propose ASGard, a novel approach that generates API usage templates from examples. Approximating the formal problem of E-generalization, ASGard generalizes all syntactic and some semantic information within the examples to arrive at pseudocode representations that retain the commonality of the usage examples but abstract the varying aspects. We evaluate the templates from our approach and the patterns generated from PAM and MUDetect (two existing tools for API data mining), using a total of 1,954 API usage examples across 59 different APIs. We measure the quality of the resulting templates: ASGard’s templates have superior completeness and compression. We perform a user study on ASGard with 12 participants to compare the use of these templates in solving programming tasks, compared to MUDetect. We find that participants solved the programming tasks in significantly less time with ASGard. Participants expressed a general preference for using ASGard templates.

Change is inevitable for software systems to deal with the evolving environment surrounding them, and applying changes requires careful design and implementation not to break existing functionalities. Evolution in software product lines (SPLs) is more complex compared to evolution for individual products: a change applied to a single feature might affect all the products in the whole product family. In this paper we present an approach for change impact analysis in delta-oriented programming (DOP), an existing language aimed at supporting SPLs. We propose the CIAHelper tool to identify dependencies within a DOP program, by analyzing the semantics of both the code artifacts and variability models to construct a directed dependency graph. We also consider how the source code history could be used to enhance the recall of detecting the affected artifacts given a change proposal. We evaluate our approach by means of five case studies on two different DOP SPLs.

Deprecation allows the developers of application programming interfaces (APIs) to signal to other developers that a given API item ought to be avoided. But little is known about deprecation practices beyond anecdotes. We examine how API deprecation has been used in 26 open source Java frameworks and libraries, finding that the classic deprecate–replace–remove cycle is often not followed, as many APIs were removed without prior deprecation, many deprecated APIs were subsequently un-deprecated, and removed APIs are even resurrected with surprising frequency. Furthermore, we identify several problems in the information commonly (not) provided to help API consumers transition their dependent code.

SUMMARY Traditional industrial practice often involves the ad hoc reuse of source code that was not designed for that reuse. Suchpragmatic reusetasks play an important role indisciplinedsoftware development. Pragmatic reuse has been seen as problematic due to a lack of systematic support, and an inability to validate that the reused code continues to operate correctly within the target system. Although recent work has successfully systematized support for pragmatic reuse tasks, the issue of validation remains unaddressed. In this paper, we present a novel approach and tool to semi‐automatically reuse and transform relevant portions of the test suite associated with pragmatically reused code, as a means to validate that the relevant constraints from the originating system continue to hold, while minimizing the burden on the developer. We conduct a formal experiment with experienced developers, to compare the application of our approach versus the use of a standard IDE (the ‘manual approach’). We find that, relative to the manual approach, our approach: reduces task completion time; improves instruction coverage by the reused test cases; and improves the correctness of the reused test cases. Copyright © 2012 John Wiley & Sons, Ltd.

Application programming interfaces (APIs) are a common and industrially-relevant means for third-party software developers to reuse external functionality. Several techniques have been proposed to help migrate client code between library versions with incompatible APIs, but it is not clear how well these perform in an absolute sense. We present a retroactive study into the presence and nature of API incompatibilities between several versions of a set of Java-based software libraries; for each, we perform a detailed, manual analysis to determine what the correct adaptations are to migrate from the older to the newer version. In addition, we investigate whether any of a set of adaptation recommender techniques is capable of identifying the correct adaptations for library migration. We find that a given API incompatibility can typically be addressed by only one or two recommender techniques, but sometimes none serve. Furthermore, those techniques give correct recommendations, on average, in only about 20% of cases.

It has been claimed that crosscutting concerns are pervasive and problematic, leading to difficulties in program comprehension, evolution, and long-term design degradation. To consider whether this theory bears out, we examine the patch history of the Mozilla project over a period of a decade to consider whether crosscutting concerns exist therein and whether we can see evidence of problems arising from them. Mozilla is an interesting case, due to its longevity; size; polylingual nature; and use of a patch review process, which maintains strong connections between issue reports and the patches that are intended to address each. We perform several statistical analyses of the over 200,000 patches submitted to address over 90,000 issues reported in this time period. We find that 90% of patches show little or no evidence of scattering, that the scattering of a patch tends to decrease slightly upon review on average, and that the system shows at worst a slow increase of average scattering over time.

Many software reuse tasks involve reusing source code that was not designed in a manner conducive to those tasks, requiring that ad hoc modifications be applied. Such pragmatic reuse tasks are a reality in disciplined industrial practice; they arise for a variety of organizational and technical reasons. To investigate a pragmatic reuse task, a developer must navigate through, and reason about, source code dependencies in order to identify program elements that are relevant to the task and to decide how those elements should be reused. The developer must then convert his mental model of the task into a set of actions that he can perform. These steps are poorly supported by modern development tools and practices. We provide a model for the process involved in performing a pragmatic reuse task, including the need to capture (mentally or otherwise) the developer's decisions about how each program element should be treated: this is a pragmatic-reuse plan . We provide partial support for this model via a tool suite, called Gilligan; other parts of the model are supported via standard IDE tools. Using a pragmatic-reuse plan, Gilligan can semiautomatically transform the selected source code from its originating system and integrate it into the developer's system. We have evaluated Gilligan through a series of case studies and experiments (each involving industrial developers) using a variety of source systems and tasks; we report in particular on a previously unpublished, formal experiment. The results show that pragmatic-reuse plans are a robust metaphor for capturing pragmatic reuse intent and that, relative to standard IDE tools, Gilligan can (1) significantly decrease the time that developers require to perform pragmatic reuse tasks, (2) increase the likelihood that developers will successfully complete pragmatic reuse tasks, (3) decrease the time required by developers to identify infeasible reuse tasks, and (4) improve developers' sense of their ability to manage the risk in such tasks.

Issue tracking systems help organizations manage issue reporting, assignment, tracking, resolution, and archiving. Traditionally, it is the Software Engineering community that researches issue tracking systems, where software defects are reported and tracked as 'bug reports' within an archival database. Yet, as issue tracking is fundamentally a social process, it is important to understand the design and use of issue tracking systems from that perspective. Consequently, we conducted a qualitative study of issue tracking systems as used by small, collocated software development teams. We found that an issue tracker is not just a database for tracking bugs, features, and inquiries, but also a focal point for communication and coordination for many stakeholders within and beyond the software team. Customers, project managers, quality assurance personnel, and programmers all contribute to the shared knowledge and persistent communication that exists within the issue tracking system. These results were all the more striking because in spite of teams being collocated--which afforded frequent, face-to-face communication--the issue tracker was still used as a fundamental communication channel. We articulate various real-world practices surrounding issue trackers and offer design considerations for future systems.

The goal of this one-day workshop is to bring together researchers and practitioners with interest and experience in the theory, elaboration, and evaluation of concepts, techniques, and tools for providing recommendations to developers, managers, and other stakeholders involved in software engineering tasks.

It is often assumed that developers' view of their system and its environment is always consistent with everyone else's; in practice, this assumption can be false, as the developer has little practical control over changes to the environments in which their code will be deployed. To proactively respond to such situations, developers must constantly monitor a flood of information involving changes to the deployment environments; unfortunately, the vast majority of this information is irrelevant to the individual developer, and its sheer volume makes it likely that infrequent change events of relevance are overlooked. As a result, errors may arise at deployment time that the developer does not immediately detect.

Automated refactoring is a key feature of modern IDEs. Existing refactorings rely on the transformation of source code declarations, in which references may also be transformed as a side effect. However, there exist situations in which a declaration is not available for refactoring or would be inappropriate to transform, for example, in the presence of dangling references or where a set of references should be retargeted to a different declaration.

Software developers who extend or repair existing software systems spend considerable effort in understanding how their modifications will require follow-on changes in order to work correctly. Tool support for this process is available for single, popular languages, but does not suffice for less popular languages, uncommon language variants, or arbitrary combinations of languages and connection technologies. We have created the DSketch tool so that developers can create a lightweight pattern specification for how dependencies can be heuristically identified in their systems. We performed two case studies involving industrial developers who applied our tool for conducting polylingual dependency analysis in software systems; the developers found it easy to configure the tool for their needs, were able to adapt their patterns to new contexts, and had sufficiently accurate dependency predictions for their work.

Source code examples are valuable to developers needing to use an unfamiliar application programming interface (API). Numerous approaches exist to help developers locate source code examples; while some of these help the developer to select the most promising examples, none help the developer to reuse the example itself. Without explicit tool support for the complete end-to-end task, the developer can waste time and energy on examples that ultimately fail to be appropriate; as a result, the overhead required to reuse an example can restrict a developer's willingness to investigate multiple examples to find the "best" one for their situation. This paper outlines four case studies involving the end-to-end use of source code examples: we investigate the overhead and pitfalls involved in combining a few state-of-the-art techniques to support the end-to-end use of source code examples.

Planning a complex software modification task imposes a high cognitive burden on developers, who must juggle navigating the software, understanding what they see with respect to their task, and deciding how their task should be performed given what they have discovered. Pragmatic reuse tasks, where source code is reused in a white-box fashion, is an example of a complex and error-prone modification task: the developer must plan out which portions of a system to reuse, extract the code, and integrate it into their own system. In this paper we present a recommendation system that automates some aspects of the planning process undertaken by developers during pragmatic reuse tasks. In a retroactive evaluation, we demonstrate that our technique was able to provide the correct recommendation 64% of the time and was incorrect 25% of the time. Our case study suggests that developer investigative behaviour is positively influenced by the use of the recommendation system.

Developers undertaking a pragmatic reuse task must collect and reason about information that is spread throughout the source code of a system before they can understand the scope of their task. Once they have this understanding, they can undertake the manual process of actually reusing the source code within their system. We have created a tool environment to help developers plan and perform pragmatic reuse tasks enabling them to reason about and perform larger reuse tasks than they generally feel comfortable attempting otherwise.

Eclipse has evolved from a fledgling Java IDE into a mature software ecosystem. One of the greatest benefits Eclipse provides developers is flexibility; however, this is not without cost. New Eclipse developers often find the framework to be large and confusing. Determining which parts of the framework they should be using can be a difficult task as Eclipse documentation tends to be either very high-level, focusing on the design of the framework, or low-level, focusing on specific APIs. We have developed a tool called PopCon that provides a bridge between high-level design documentation and low-level API documentation by statically analyzing a framework and several of its clients and providing a ranked list of the relative popularity of its APIs. We have applied PopCon to the Eclipse framework for this challenge to help newbie Eclipse developers identify some of the most relevant APIs for their tasks.

Developers perform small-scale reuse tasks to save time and to increase the quality of their code, but due to their small scale, the costs of such tasks can quickly outweigh their benefits. Existing approaches focus on locating source code for reuse but do not support the integration of the located code within the developer's system, thereby leaving the developer with the burden of performing integration manually. This paper presents an approach that uses the developer's context to help integrate the reused source code into the developer's own source code. The approach approximates a theoretical framework (higher-order anti-unification modulo theories), known to be undecidable in general, to determine candidate correspondences between the source code to be reused and the developer's current (incomplete) system. This approach has been implemented in a prototype tool, called Jigsaw, that identifies and evaluates candidate correspondences greedily with respect to the highest similarity. Situations involving multiple candidate correspondences with similarities above a defined threshold are presented to the developer for resolution. Two empirical evaluations were conducted: an experiment comparing the quality of Jigsaw's results against suspected cases of small-scale reuse in an industrial system; and case studies with two industrial developers to consider its practical usefulness and usability issues.

Software reuse has long been promoted as a means to increase developer productivity; however, reusing source code is difficult in practice and tends to be performed in an ad hoc manner. This is problematic because poor decisions can be made either to attempt an unwise, overly complex reuse task, or to avoid a reuse task that would have saved time and effort. This paper describes a lightweight tool that supports the investigation and planning of pragmatic reuse tasks. The tool helps developers to identify the dependencies from the source code they wish to reuse, and to decide how to deal with those dependencies. Questions about pragmatic reuse are evaluated through a survey of industrial developers. The tool is evaluated through the planning and execution of reuse tasks by industrial developers.

Software dependency analysis is an important step in determining the potential impact of changes. Existing tool support for conducting dependency analysis does not sufficiently support systems written in more than one language. Tools based on semantic analyses are expensive to create for combinations of multiple languages, while lexical tools provide poor accuracy and rely heavily on developer skill. This paper reports on an investigation into the application of a series of incrementally-better island grammars to an industrial, open-source polylingual system to determine the cost-to-accuracy relationship involved in developing and applying island grammars for dependency analysis. The results of our study suggest the effort-cost in writing richer island grammars rises faster than the resulting accuracy.

When a software system undergoes modification, a given change might need to be repeated throughout the codebase. While the change itself may not be difficult to implement, discovering other locations where this change should be applied (if any exist) can be onerous. Syntactic differences in otherwise semantically similar code can render traditional search techniques ineffective. This paper describes a heuristic search technique to help find the locations required to complete a repetitive small-scale change (RSC). By observing the developer perform a change once, it is possible to infer semantic information about that change and to automatically suggest locations where the same change ought to be made

Generalization tasks are important for continual improvement to the design of an evolving code base, eliminating redundancy where it has accumulated. An important step in generalization is identifying the detailed structural correspondence between two pieces of code being considered for generalization. Unfortunately, tool support for this step is insufficient, leaving the developer to resort to tedious and error-prone manual determination of correspondence. This paper presents an approach for automatically determining correspondences as an early step in a generalization task. The approach is implemented in a proof-of-concept plug-in to the Eclipse integrated development environment. Two small empirical evaluations of the tool have been conducted: a comparison between human attempts to determine detailed correspondences and those of the tool; and, a comparison of the use of the tool to the use of diff/CCFinder in performing generalization tasks.

When coding to an application programming interface (API), developers often encounter difficulties, unsure of which class to subclass, which objects to instantiate, and which methods to call. Example source code that demonstrates the use of the API can help developers make progress on their task. This paper describes an approach to provide such examples in which the structure of the source code that the developer is writing is matched heuristically to a repository of source code that uses the API. The structural context needed to query the repository is extracted automatically from the code, freeing the developer from learning a query language or from writing their code in a particular style. The repository is generated automatically from existing applications, avoiding the need for handcrafted examples. We demonstrate that the approach is effective, efficient, and more reliable than traditional alternatives through four empirical studies

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.

This paper introduces declarative event patterns (DEPs) as a means to implement protocols while improving their traceability, comprehensibility, and maintainability. DEPs are descriptions of sequences of events in the execution of a system that include the ability to recognize properly nested event structures. DEPs allow a developer to describe a protocol at a high-level, without the need to express extraneous details. A developer can indicate that specific actions be taken when a given pattern occurs. DEPs are automatically translated into the appropriate instrumentation and automaton for recognizing a given pattern. Support for DEPs has been implemented in a proof-of-concept extension to the AspectJ language that is based on advanced compiler technology. A case study is described that compares the use of DEPs in the implementation of a protocol (FTP user authentication) to the use of a set of other approaches, both object-oriented and aspect-oriented.

Most software systems are inflexible. Reconfiguring a system's modules to add or to delete a feature requires substantial effort. This inflexibility increases the costs of building variants of a system, amongst other problems. New languages and tools that are being developed to provide additional support for separating concerns show promise to help address this problem. However applying these mechanisms requires determining how to enable a feature to be separated from the codebase. We investigate this problem through an exploratory study conducted in the context of two existing systems: gnu.regexp and jFTPd. The study consisted of applying three different separation of concern mechanisms: Hyper/J/sup TM/ AspectJ/sup TM/ and a lightweight, lexically-based approach, to separate features in the two packages. We report on the study, providing contributions in two areas. First, we characterize the effect different mechanisms had on the structure of the codebase. Second, we characterize the restructuring process required to perform the separations. These characterizations can help researchers to elucidate how the mechanisms may be best used, tool developers to design support to aid the separation process, and early adopters to apply the techniques.

Software systems should consist of simple, conceptually clean software components interacting along narrow, well-defined paths. All too often, this is not reality: complex components end up interacting for reasons unrelated to the functionality they provide. We refer to knowledge within a component that is not conceptually required for the individual behaviour of that component as extraneous embedded knowledge (EEK). EEK creeps into a system in many forms, including dependences upon particular names and the passing of extraneous parameters. This paper proposes the use of implicit context as a means for reducing EEK in systems by combining a mechanism to reflect upon what has happened in a system, through queries on the call history, with a mechanism for altering calls to and from a component. We demonstrate the benefits of implicit context by describing its use to reduce EEK in the Java™ Swing library.

No abstract available.

The principle of separation of concerns has long been used by software engineers to manage the complexity of software system development.Programming languages help software engineers explicitly maintain the separation of some concerns in code.As another step towards increasing the scope of concerns that can be captured cleanly within the code, Kiczales and colleagues have introduced aspect-oriented programming.In aspect-oriented programming, explicit language support is provided to help modularize design decisions that cross-cut a functionally-decomposed program.Aspect-oriented programming is intended to make it easier to reason about, develop, and maintain certain kinds of application code.To investigate these claims, we conducted two exploratory experiments that considered the impact of aspect-oriented programming, as found in AspectJ version 0.1, on two common programming activities: debugging and change.Our experimental results provide insights into the usefulness and usability of aspect-oriented programming.Our results also raise questions about the characteristics of the interface between aspects and functionallydecomposed core code that are necessary to accrue programming benefits.Most notably, the separation provided by aspect-oriented programming seems most helpful when the interface is narrow (i.e., the separation is more complete); partial separation does not necessarily provide partial benefit.

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.

Dynamic information collected as a software system executes can help software engineers perform some tasks on a system more effectively. To interpret the sizable amount of data generated from a system's execution, engineers require tool support. We have developed an off-line, flexible approach for visualizing the operation of an object-oriented system at the architectural level. This approach complements and extends existing profiling and visualization approaches available to engineers attempting to utilize dynamic information. In this paper, we describe the technique and discuss preliminary qualitative studies into its usefulness and usability. These studies were undertaken in the context of performance tuning tasks.