Mik Kersten

An Overview of AspectJ

Aspect] is a simple and practical aspect-oriented extension to Java With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns. In AspectJs dynamic join point model, join points are well-defined points in the execution of the program; pointcuts are collections of join points; advice are special method-like constructs that can be attached to pointcuts; and aspects are modular units of crosscutting implementation, comprising pointcuts, advice, and ordinary Java member declarations. AspectJ code is compiled into standard Java bytecode. Simple extensions to existing Java development environments make it possible to browse the crosscutting structure of aspects in the same kind of way as one browses the inheritance structure of classes. Several examples show that AspectJ is powerful, and that programs written using it are easy to understand.

Getting started with ASPECTJ

Many software developers are attracted to the idea of AOP, but unsure about how to begin using the technology. They recognize the concept of crosscutting concerns, and know that they have had problems with the implementation of such concerns in the past. But there are many questions about how to adopt AOP into the development process. Common questions include: Can I use aspects in my existing code? What kinds of benefits can I expect to get? How do I find aspects? How steep is the learning curve for AOP? What are the risks of using this new technology?

Using task context to improve programmer productivity

When working on a large software system, a programmer typically spends an inordinate amount of time sifting through thousands of artifacts to find just the subset of information needed to complete an assigned task. All too often, before completing the task the programmer must switch to working on a different task. These task switches waste time as the programmer must repeatedly find and identify the information relevant to the task-at-hand. In this paper, we present a mechanism that captures, models, and persists the elements and relations relevant to a task. We show how our task context model reduces information overload and focuses a programmers work by filtering and ranking the information presented by the development environment. A task context is created by monitoring a programmers activity and extracting the structural relationships of program artifacts. Operations on task contexts integrate with development environment features, such as structure display, search, and change management. We have validated our approach with a longitudinal field study of Mylar, our implementation of task context for the Eclipse development environment. We report a statistically significant improvement in the productivity of 16 industry programmers who voluntarily used Mylar for their daily work.

How are Java software developers using the Elipse IDE

The Eclipse integrated development environment continues to gain popularity among Java developers. Our usage monitoring approach allows tool builders to sample how developers are using their tools in the wild. The data gathered about tool use can be used to prevent feature bloat and to evolve the environments according to user needs. Information about how developers work in a development environment can also provide a baseline for assessing new software development tools. We hope this report provides a start in defining which in formation to collect and distribute on an on going basis to help improve Eclipse and other similar platforms and tools

Mylar: a degree-of-interest model for IDEs

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

Atlas: a case study in building a web-based learning environment using aspect-oriented programming

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 Microsystems Java#8482; Servlet specification using Xerox PARCs aspect-oriented programming support called Aspect#8482;. 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.

The emergent structure of development tasks

Integrated development environments have been designed and engineered to display structural information about the source code of large systems. When a development task lines up with the structure of the system, the tools in these environments do a great job of supporting developers in their work. Unfortunately, many development tasks do not have this characteristic. Instead, they involve changes that are scattered across the source code and various other kinds of artifacts, including bug reports and documentation. Todays development environments provide little support for working with scattered pieces of a system, and as a result, are not adequately supporting the ways in which developers work on the system. Fortunately, many development tasks do have a structure. This structure emerges from a developers actions when changing the system. In this paper, we describe how the structure of many tasks crosscuts system artifacts, and how by capturing that structure, we can make it as easy for developers to work on changes scattered across the systems structure as it is to work on changes that line up with the systems structure.

Does aspect-oriented programming work?

Wouldn’t it be advantageous to know in advance that the use of AOP[3] for your next project would be successful? Unfortunately, developersand managers seldom have access to evidence assuring them that thebenefits promised by a new technology, such as AOP, will be achieved ifthey adopt the technology. Instead, they must take a leap of faith, believ-ing the technology will help them overcomeproblems encountered previously. To thoroughly evaluate the usefulness of AOP, multiple softwaredevelopment organizations would need to build their products bothwith and without AOP and compare the results. Such an approach isunrealistic. Is the situation then hopeless? Can software engineeringresearchers provide any help to determine if it is beneficial for softwaredevelopment organizations to adopt AOP for building their softwareproducts? We believe researchers can provide help. Toward that goal, a Gail C. Murphy, Robert J. Walker, ElisaL.A. Baniassad, Martin P. Robillard,Albert Lai, and Mik A. Kersten

Software and Culture: Beyond the Internationalization of the Interface

Software applications are designed around user interaction. One interaction component is the user interface; the other deeper components represent the applications’ logic and core functionality. Internationalization architectures recognize the need for localizing user interfaces to particular cultures. We continue the discussion on culture and software focusing on the software core rather than the user interface. This core corresponds to deep culture as opposed to the surface cultural manifestations embedded in the user interface. We argue here that deep culture can be embedded into application software in a modular way.

Focusing knowledge work with task context

By making information easy to browse and query, current software tools make it possible for knowledge workers to access vast amounts of information available in document repositories and on the web. However, when displaying dozens of web page search hits, hundreds of files and folders in a document hierarchy, or tens of thousands of lines of source code, these tools overload knowledge workers with information that is not relevant to the task-at-hand. The result is that knowledge workers waste time clicking, scrolling, and navigating to find the subset of information needed to complete a task. This problem is exacerbated by the fact that many knowledge workers constantly multi-task. With each task switch, they lose the context that they have built up in the browsing and query views. The combination of context loss and information overload has adverse effects on productivity because it requires knowledge workers to repeatedly locate the information that they need to complete a task. The larger the amount of information available and the more frequent the multi-tasking, the worse the problem becomes. We propose to alleviate this problem by focusing the software applications a knowledge worker uses on the information relevant to the task-at-hand. We represent the information related to the task with a task context model in which the relevant elements and relations are weighted according to their frequency and recency of access. We define operations on task context to support tailoring the task context model to different kinds of knowledge work activities. We also describe task-focused user interface mechanisms that replace the structure-centric display of information with a task-centric one. We validate the task context model with three field studies. Our preliminary feasibility study of six industry programmers tested a prototype implementation of the task context model and task-focused user interface for an integrated development environment. Our second study involved sixteen industry programmers using a production quality implementation of the task context model; these programmers experienced a statically significant increase in productivity when using task context. Our third field study tested a prototype implementation of the task context model for a file and web browsing application. The results of this study showed that task context generalizes beyond programming applications, reducing information overload and facilitating multi-tasking in a cross-section of knowledge work domains.