Modern integrated development environments (IDEs) make many software engineering tasks easier by providing automated programming support such as code completion and navigation. However, such support -- and therefore IDEs as awhole -- operate on one revision of the code at a time, and leave handling of code history to external tools or plugins, such asEGit for Eclipse. For example, when a method is removed froma class, developers can no longer find the method through code completion. This forces developers to manually switch across different revisions or resort to using external tools when they need to learn about previous code revisions.We propose a novel approach of adding a temporal dimensionto IDEs, enabling code completion and navigation to operate on multiple revisions of code at a time. We previously introduced the idea of temporal code completion and navigation,and presented a vision for how that idea may be realized.This paper realizes that vision by implementing and evaluatinga prototype tool called Tempura. We describe our algorithmfor processing and indexing historical code information from repositories for Tempura, and demonstrate Tempura's scalability with three large Eclipse projects. We also evaluate Tempura's usability through a controlled user study. The study participantslearned about the code history with more accuracy when usingTempura compared to EGit. Although the sample size was notlarge enough to provide strong statistical significance, the resultsshow a promising outlook for our approach.

Type qualifier inference tools usually operate in batch mode and assume that the program must not be changed except to add the type qualifiers. In practice, programs must be changed to make them type-correct, and programmers must understand them. Cascade is an interactive type qualifier inference tool that is easy to implement and universal (i.e., it can work for any type qualifier system for which a checker is implemented). It shows that qualifier inference can achieve better results by involving programmers rather than relying solely on automation.

Identifying repetitive code changes benefits developers, tool builders, and researchers. Tool builders can automate the popular code changes, thus improving the productivity of developers. Researchers can better understand the practice of code evolution, advancing existing code assistance tools and benefiting developers even further. Unfortunately, existing research either predominantly uses coarse-grained Version Control System (VCS) snapshots as the primary source of code evolution data or considers only a small subset of program transformations of a single kind - refactorings.

Modern Integrated Development Environments (IDEs) support many refactorings. Yet, programmers greatly underuse automated refactorings. Recent studies have applied traditional usability testing methodologies such as surveys, lab studies, and interviews to find the usability problems of refactoring tools. However, these methodologies can identify only certain kinds of usability problems. The critical incident technique (CIT) is a general methodology that uncovers usability problems by analyzing troubling user interactions. We adapt CIT to refactoring tools and show that alternate refactoring paths are indicators of the usability problems of refactoring tools. We define an alternate refactoring path as a sequence of user interactions that contains cancellations, reported messages, or repeated invocations of the refactoring tool. We evaluated our method on a large corpus of refactoring usage data, which we collected during a field study on 36 programmers over three months. This method revealed 15 usability problems, 13 of which were previously unknown. We reported these problems and proposed design improvements to Eclipse developers. The developers acknowledged all of the problems and have already fixed four of them. This result suggests that analyzing alternate paths is effective at discovering the usability problems of interactive program transformation (IPT) tools.

Refactoring is a disciplined technique for restructuring code to improve its readability and maintainability. Almost all modern integrated development environments (IDEs) offer built-in support for automated refactoring tools. However, the user interface for refactoring tools has remained largely unchanged from the menu and dialog approach introduced in the Smalltalk Refactoring Browser, the first automated refactoring tool, more than a decade ago. As the number of supported refactorings and their options increase, invoking and configuring these tools through the traditional methods have become increasingly unintuitive and inefficient. The contribution of this paper is a novel approach that eliminates the use of menus and dialogs altogether. We streamline the invocation and configuration process through direct manipulation of program elements via drag-and-drop. We implemented and evaluated this approach in our tool, Drag-and-Drop Refactoring (DNDRefactoring), which supports up to 12 of 23 refactorings in the Eclipse IDE. Empirical evaluation through surveys and controlled user studies demonstrates that our approach is intuitive, more efficient, and less error-prone compared to traditional methods available in IDEs today. Our results bolster the need for researchers and tool developers to rethink the design of future refactoring tools.

Emerging applications in the domains of recognition, mining and synthesis (RMS); image and video processing; data warehousing; and automatic financial trading admit a particular style of parallelism termed flow-based parallelism. To help developers exploit flow-based parallelism, popular parallel libraries such as Groovy's GPars, Intel's TBB Flow Graph and Microsoft's TPL Dataflow have begun introducing many new and useful constructs. However, to reap the benefits of such constructs, developers must first use them. This involves refactoring their existing sequential code to incorporate these constructs - a manual process that overwhelms even experts. To alleviate this burden, we introduce a set of novel analyses and transformations targeting flow-based parallelism. We implemented these ideas in JFlow, an interactive refactoring tool integrated into the Eclipse IDE. We used JFlow to parallelize seven applications: four from a previously known benchmark and three from a suite of large open source projects. JFlow, with minimal interaction from the developer, can successfully parallelize applications from the aforementioned domains with good performance (offering up to 3.45x speedup on a 4-core machine) and is fast enough to be used interactively as part of a developer's workflow.

Actor programs are concurrent programs where concurrent entities communicate asynchronously by exchanging messages. Testing actor programs is challenging because the order of message receives depends on the non-deterministic scheduler and because exploring all schedules does not scale to large programs. This paper presents Bita, a scalable, automatic approach for testing non-deterministic behavior of actor programs. The key idea is to generate and explore schedules that are likely to reveal concurrency bugs because these schedules increase the schedule coverage. We present three schedule coverage criteria for actor programs, an algorithm to generate feasible schedules that increase coverage, and a technique to force a program to comply with a schedule. Applying Bita to real-world actor programs implemented in Scala reveals eight previously unknown concurrency bugs, of which six have already been fixed by the developers. Furthermore, we show our approach to find bugs 122× faster than random scheduling, on average.

ABSTRACT C preprocessor directives are heavily used in C programs because they provide useful and even necessary additions to the C language. However, they are usually executed and discarded before any analysis is applied on C programs. In refactoring, preprocessor directives must be preserved through the whole process of parsing, analysis and transformation to retain editable yet correct source code. We propose a new preprocessing approach and special program representations that allow a program to be analyzed and transformed without losing its preprocessor directives, but treating them as first‐class program entities. These representations are essential for a correct refactoring tool. We also describe the challenges that preprocessor directives bring to refactoring and how the program representations that we propose solve those challenges. Finally, we give details of two refactorings and present some case studies with our successfully applied solution. Copyright © 2013 John Wiley & Sons, Ltd.

Though refactoring tools have been available for more than a decade, research has shown that programmers underutilize such tools. However, little is known about why programmers do not take advantage of these tools. We have conducted a field study on programmers in their natural settings working on their code. As a result, we collected a set of interaction data from about 1268 hours of programming using our minimally intrusive data collectors. Our quantitative data show that programmers prefer lightweight methods of invoking refactorings, usually perform small changes using the refactoring tool, proceed with an automated refactoring even when it may change the behavior of the program, and rarely preview the automated refactorings. We also interviewed nine of our participants to provide deeper insight about the patterns that we observed in the behavioral data. We found that programmers use predictable automated refactorings even if they have rare bugs or change the behavior of the program. This paper reports some of the factors that affect the use of automated refactorings such as invocation method, awareness, naming, trust, and predictability and the major mismatches between programmers' expectations and automated refactorings. The results of this work contribute to producing more effective tools for refactoring complex software.

One of the most difficult parts of building automated refactorings is ensuring that they preserve behavior. This paper proposes a new technique to check for behavior preservation; we call this technique differential precondition checking. It is simple yet expressive enough to implement the most common refactorings, and the core algorithm runs in linear time. However, the main advantage is that a differential precondition checker can be placed in a library and reused in refactoring tools for many different languages; the core algorithm can be implemented in a way that is completely language independent. We have implemented a differential precondition checker and used it in refactoring tools for Fortran (Photran), PHP, and BC.

Software patterns have been used to guide developers and to disseminate expert knowledge. But patterns can also be thought of as program transformations. Security patterns are architectural. Therefore, program transformations derived from those patterns transform architecture. This paper describes how we used a catalog of security patterns to produce a catalog of security-oriented program transformations. These transformations can be used to make architectural changes that make systems more secure. This paper is a first example of applying patterns to actively transform architectures.

Many computer science research efforts fail. Some of this is inevitable, since research is risky. But sometimes the agenda of a group of researchers fails because there is a part of the problem that everyone agrees is crucial, but that nobody works on. Often this is because there are not enough rewards for working on it; it is hard to publish and/or there is no funding. This is more common than you might think; I call it the classic catastrophic computer science failure mode.Design could have fallen into this trap. Our hypothesis was standard description of design techniques will enable new designers to become expert faster and will improve the design process for experts. I don't believe we have proven this hypothesis yet, though there is a lot of anecdotal evidence for it. A key step in proving it is developing the standard description of design techniques, and Design Patterns is part of that. There were lots of reasons not to write the book. Who were we to try to standardize design? How did we know we had the right patterns? These are unanswerable questions, so we focused on writing the catalog and let other people decide whether it was worthwhile. Other people publicized it for us. Without those people, it would not have made much of an impact.Other projects have not been so fortunate. I've seen several projects fail because they needed something like a catalog, but nobody worked on developing it. This talk will describe warning signs of the classic catastrophic computer science failure mode and how to avoid it.

Effect systems are important for reasoning about the side effects of a program. Although effect systems have been around for decades, they have not been widely adopted in practice because of the large number of annotations that they require. A tool that infers effects automatically can make effect systems practical. We present an effect inference algorithm and an Eclipse plug-in, DPJizer, which alleviate the burden of writing effect annotations for a language called Deterministic Parallel Java (DPJ). The key novel feature of the algorithm is the ability to infer effects on nested heap regions. Besides DPJ, we also illustrate how the algorithm can be used for a different effect system based on object ownership. Our experience shows that DPJizer is both useful and effective: (i) inferring effect annotations automatically saves significant programming burden; and (ii) inferred effects are more precise than those written manually, and are fine-grained enough to enable the compiler to prove determinism of the program.

Successful programming languages change as they age. They tend to become more complex, and eventually some features become outdated or are rarely used. Programming tools for these languages become more complex as well, since they have to support archaic features. Old programs are hard to maintain, since these archaic features are unfamiliar to modern programmers. These problems can be solved by refactoring tools that can transform programs to use the modern form. We show that refactoring tools can ease the cost of program evolution by examining the evolution of two languages, Fortran and Java, and showing that each change corresponds to an automatable refactoring.

Although in theory the APIs of software libraries and frameworks should be stable, they change in practice. This forces clients of the library API to change as well, making software maintenance expensive. Changing a client might not even be an option if its source code is missing or certain policies forbid its change. By giving a library both the old and the new API, clients can be shielded from API changes and can run with the new version of the library.

Abstract As the Internet matured, security became more important and formerly adequate designs became inadequate. One of the victims of the increased need for security wassendmail. This paper shows how its competitors improved on its design in response to the increased need for security. The designers ofqmailandPostfixused well‐known patterns to achieve better security without affecting performance; these patterns can be used by the designers of other systems with an increased need for security. Copyright © 2008 John Wiley & Sons, Ltd.

Current text based Software Configuration Management (SCM) systems have trouble with refactorings. Refactorings result in global changes which lead to merge conflicts. A refactoring-aware SCM system reduces merge conflicts. This paper describes MolhadoRef, a refactoring-aware SCM system and the merge algorithm at its core. MolhadoRef records change operations (refactorings and edits) used to produce one version, and replays them when merging versions. Since refactorings are change operations with well defined semantics, MolhadoRef treats them intelligently. A case study and a controlled experiment show that MolhadoRef automatically solves more merge conflicts than CVS while resulting in fewer merge errors.

Current text based software configuration management (SCM) systems have trouble with refactorings. Refactorings result in global changes and lead to merge conflicts. A refactoring-aware SCM system reduces merge conflicts, preserves program history better and makes it easier to understand program evolution. This paper describes MolhadoRef a refactoring-aware SCM system and the merge algorithm at its core. MolhadoRef records change operations (refactorings and edits) used to produce one version, and replays them when merging versions. Since refactorings are change operations with well defined semantics, MolhadoRef treats them intelligently. A case-study shows that MolhadoRef solves automatically more merge conflicts than CVS while resulting in fewer merge errors.

Race conditions are hard to detect in frameworkbased applications. Frameworks often improve performance by providing threading, but this threading is usually hidden from application programmers. Therefore, it is easy for application programmers to accidentally create data races. Data races can be detected tracing the flow of execution, but tracing tends to produce too much data. However, the structure of frameworks can be used to control the amount of data collected and that makes tracing practical. We have developed a tracing and analysis tool that allows application programmers to explore different configurations of an application and find probable data races. This enables them to have mutithreaded frameworks safely without having to learn the details of the framework design.

Design patterns capture software solutions to specific problems that have evolved over time and reflect many iterations of work. Documenting such patterns promotes proven design and software reuse. There has been a growing amount of work documenting design patterns for security, however, little work specific to VoIP security. In 2005 NIST released a report on recommendations and best practices for securing VoIP, however it lacks the structure, terminology, and ease-of-understanding needed for both technical and non-technical audiences that is an inherent feature of design patterns. In this paper, we document three design patterns for VoIP implementations related to specific security problems: (1) secure traversal of firewalls and NATs; (2) detecting and mitigating DDoS attacks; and (3) securing against eavesdropping. With many VoIP vendors rushing products to market with overlapping functionality and requirements for interoperability, documenting design patterns is poised to become an important part of secure programming processes for VoIP

Abstract Frameworks and libraries change their APIs. Migrating an application to the new API is tedious and disrupts the development process. Although some tools and ideas have been proposed to solve the evolution of APIs, most updates are done manually. To better understand the requirements for migration tools, we studied the API changes of four frameworks and one library. We discovered that the changes that break existing applications are not random, but tend to fall into particular categories. Over 80% of these changes are refactorings. This suggests that refactoring‐based migration tools should be used to update applications. Copyright © 2006 John Wiley & Sons, Ltd.

Transactions are an important part of most enterprise computing systems. Sometimes they are supported by DBMS and sometimes by transaction monitors. In either case, they are part of the platform used by application developers. A platform independent model of enterprise computing must abstract away transactions and provide platform independent ways of describing them. This paper shows how "unit of work" can be used to support platform independent descriptions of enterprise computing systems that use transactions. Our paper is in the context of the OMG's model driven architecture so we provide a UML profile for describing unit of work. We have developed a tool, Mercator, that can translate platform independent models using the unit of work profile to platform dependent models using transactions. When added to our previous work on persistence, this provides a general way of handling transparent transaction management in MDA.

Frameworks and libraries change their APIs. Migrating an application to the new API is tedious and disrupts the development process. Although some tools and ideas have been proposed to solve the evolution of APIs, most updates are done manually. To better understand the requirements for migration tools we studied the API changes of three frameworks and one library. We discovered that the changes that break existing applications are not random, but they tend to fall into particular categories. Over 80% of these changes are refactorings. This suggests that refactoring-based migration tools should be used to update applications.

Preprocessor conditionals are heavily used in C programs since they allow the source code to be configured for different platforms or capabilities. However, preprocessor conditionals, as well as other preprocessor directives, are not part of the C language. They need to be evaluated and removed, and so a single configuration selected, before parsing can take place. Most analysis and program understanding tools run on this preprocessed version of the code so their results are based on a single configuration. This paper describes the approach of CRefactory, a refactoring tool for C programs. A refactoring tool cannot consider only a single configuration: changing the code for one configuration may break the rest of the code. CRefactory analyses the program for all possible configurations simultaneously. CRefactory also preserves preprocessor directives and integrates them in the internal representations. The paper also presents metrics from two case studies to show that CRefactory's program representation is practical.

Summary form only given. Refactoring is usually described as a way to keep software as simple as possible, or as a way to reuse parts of a software system that were not designed to be reusable. But it has other uses. One of the problems with using software components is that new versions of the components require changes in the systems that use them. If the change from one version of a component to another is described as a set of re factorings then the parts of the system that use them can be automatically changed to use the new versions of the component. This makes it much easier for developers to use the latest versions of components.

Refactoring, an important technique for increasing flexibility of the source code, can be applied with much ease and efficiency by using automated tools. There is currently a lack of refactoring tools for C with full support for preprocessor directives because directives complicate refactorings in many ways. This paper describes refactoring of C programs in the presence of conditional compilation directives and how we propose to support them in a refactoring tool.

Patterns and frameworks are two approaches to the development of both new and evolving software systems. An implicit hypothesis is that are reduced by leveraging knowledge previously collected, analyzed, organized, and packaged. Discovery (or getting started costs) include both the costs of understanding the problem to be solved and the cost of understanding the tools, methods, existing software, etc. For large, multi-year development projects in industries such as defense or telecommunications, discovery costs can dominate the overall cost (and risk) of software development.This panel will share its experience and perspectives with the audience with a discussion initiated by the following questions:• Have patterns and frameworks really delivered on their claims for reducing discovery costs? Can current best-practices be characterized as meaningful or marginal (what are the measures)?• What are the discovery cost factors where frameworks and patterns appear to deliver the biggest bang for the buck?• While mature pattern languages and frameworks may reduce the learning curve, they do not, eliminate it. How much of a learning curve is required to develop a sufficient shared context with the authors of a set of patterns or a framework?

Frameworks and domain-specific visual languages are two different reuse techniques, the first targeted at expert programmers, the second at domain experts. In fact, these techniques are closely related. This paper shows how to develop a domain-specific visual language by first developing a white-box framework for the domain, then turning it into a black-box framework, and finally building a graphical front end for it. We used this technique in a compiler to specify run-time systems.

Writing software to control networks is important and difficult. It must be efficient, reliable, and flexible. Conduits+ is a framework for network software that has been used to implement the signalling system of a mullti-protocol ATM access switch. An earlier version was used to implement TCP/IP. It reduces the complexity of network software, makes it easier to extend or modify network protocols, and is sufficiently efficient. Conduits+ shows the power of a componentized object-oriented framework and of common object-oriented design patterns.

Article How to get a paper accepted at OOPSLA (panel) Share on Authors: Ralph E. Johnson View Profile , Kent Beck View Profile , Grady Booch View Profile , William Cook View Profile , Richard Gabriel View Profile , Rebecca Wirfs-Brock View Profile Authors Info & Claims OOPSLA '93: Proceedings of the eighth annual conference on Object-oriented programming systems, languages, and applicationsOctober 1993 Pages 429–436https://doi.org/10.1145/165854.165934Online:01 October 1993Publication History 5citation1,315DownloadsMetricsTotal Citations5Total Downloads1,315Last 12 Months35Last 6 weeks8 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

The documentation for a framework must meet several requirements.These requirements can all be met by structuring the documentation as a set of patterns, sometimes called a "pattern language".Patterns can describe the purpose of a framework, can let application programmers use a fmework without having to understand in detail how it works, and can teach many of the design details embodied in the frame work.This paper shows how to use patterns to document a framework, and includes a set ofpatterns forHotDmw as an example.Christopher Alexander, an architect, developed the idea of a "pattern language" to enable people to design their own homes and communities [Alexander et.al.].A pattern language is a set of patterns, each of which describes how to solve a particular kind of problem.His pattern language starts at a very large scale, explaining how the world should be broken into nations and nations into smaller regions, and goes on to explain how to arrange roads, parking, shopping, places to work, homes, and places of worship.The patterns focus on finer and finer levels of detail, passing though a discussion of how to arrange rooms in a house, and finally describing the type of material to use for walls, how to decorate rooms, and how to provide lighting.Alexander's pattern language is supposed to be a document that non-architects can use to design their own communities and homes.No specialized training is needed to use it.It focuses on common design problems that non-architects will encounter, like how to build bedrooms and row houses, rather than uncommon ones, like how to build concert halls and cathedrals.

article Free Access Share on Object-oriented megaprogramming (panel) Authors: Peter Wegner View Profile , William Scherlis View Profile , James Purtilo View Profile , David Luckham View Profile , Ralph Johnson View Profile Authors Info & Claims ACM SIGPLAN NoticesVolume 27Issue 10Oct. 1992 pp 392–396https://doi.org/10.1145/141937.141968Published:31 October 1992Publication History 1citation258DownloadsMetricsTotal Citations1Total Downloads258Last 12 Months9Last 6 weeks1 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

This paper describes a type system for Smalltalk that is type-safe, that allows most Smalltalk programs to be type-checked, and that can be used as the basis of an optimizing compiler.

Computational reflection makes it easy to solve problems that are otherwise difficult to address in Smalltalk-80, such as the construction of monitors, distributed objects, and futures, and can allow experimentation with new inheritance, delegation, and protection schemes. Full reflection is expensive to implement. However, the ability to override method lookup can bring much of the power of reflection to languages like Smalltalk-80 at no cost in efficiency.

TS (Typed Smalltalk) is a portable optimizing compiler that produces native machine code for a typed variant of Smalltalk, making Smalltalk programs much faster. This paper describes the structure of TS, the kinds of optimizations that it performs, the constraints that it places upon Smalltalk, the constraints placed upon it by an interactive programming environment, and its performance.

Kyma is an object-oriented environment for music composition written in Smalltalk-80, which, in conjunction with a microprogrammable digital signal processor called the Platypus, provides the composer with a means for creating and manipulating Sound objects graphically with real-time sonic feedback via software synthesis. Kyma draws no distinctions between the materials and the structure of a composition; both are Sound objects. When a Sound object receives a message to play, it transforms itself into a microSound object, i.e. an object representation of itself in the microcode of the Platypus. Thus an object paradigm is used not only in the representation of Sound objects in Smalltalk-80 but also in the microcode representation of those Sound objects on the Platypus.

Although most attempts to speed-up Smalltalk have focused on providing more efficient interpreters, code optimization is probably necessary for further increases in speed. A type-system for Smalltalk is a prerequisite for building an optimizing compiler. Unfortunately, none of the type-systems so far proposed for Smalltalk are adequate; they either cause nearly all Smalltalk programs to be type incorrect, allow run-time type errors, or do not provide enough information for optimization. This paper presents a type-system for Smalltalk that is suitable for code optimization.

Abstract: Similarity is introduced as a model-independent characterization of symmetry. It can be used to decide when a concurrent system has a solution to the selection problem. It can also be used to compare different models of parallel computation, including differences in scheduling policy and instruction set, and the consequences of using randomization. 1.