Practitioners Reports

Chair: Kresten Krab Thorup, Trifork, pract_rpts@oopsla.acm.org

Practitioner reports explore how concepts that sound good on paper (and at conferences!) work on real projects. They are a valuable means of communicating experiences, especially at the "bleeding edge" of technology. Many attendees want to find out what it is like to adopt a new language or platform, use new engineering methods, develop B2B applications, develop frameworks, use design patterns, etc.

15:30-17:00

13:30-15:00

15:30-17:00

Tools

Tuesday, 28 October – 15:30-17:00

Experience in Developing the UrbanSim System: Tools for Developing Research Software for a Politically Charged Domain

Bjorn Freeman-Benson, Center for Urban Simulation and Policy Analysis, University of Washington, bnfb@cs.washington.edu
Alan Borning, Department of Computer Science and Engineering, University of Washington, borning@cs.washington.edu

UrbanSim is a sophisticated simulation system for modeling urban land use, transportation, and environmental impacts, over a period of 20 or more years, under alternate possible scenarios. Our purpose is to support democratic decision-making on such issues as building new transit systems or freeways, or changing zoning or economic incentives, as well as on broader issues such as sustainable, livable cities, economic vitality, social equity, and environmental preservation. The domain is politically charged, with different stakeholders bringing strongly held values to the table. Our goal is not to favor any particular stakeholder values, but rather to let the stakeholders evaluate the results themselves. This need for neutrality has several implications for the development process, among other things resulting in our choice of an open source/open process model. UrbanSim is also an NSF-funded infrastructure project with a mix of research and development goals. Unlike most academic projects, this one has real customers (municipal planning organizations) with real needs.

Thus the UrbanSim project has a number of simultaneous goals, which are in some tension: producing credible, reliable code; utilizing a flexible process that adapts to new research discoveries; maintaining coherent architecture and continuous development progress; and using part-time and inexperienced student staff in addition to experienced full-time staff. (This is in contrast to the usual model in XP and other agile development processes, in which all developers are considered equally experienced and skilled.)

In this report, we discuss the tools we have chosen, modified, or developed in-house; and the reasons why these tools are good choices for this mixed research/product development environment. Our tools include: Eclipse, MySQL, CVS, Ant, Fireman (a Tinderbox-like automatic build and test system), JUnit, FIT, Wiki, Bugzilla, a physical traffic light, and a daily project dashboard. The tools are tightly integrated and collectively support our agile process.

Experiences using an ODBMS for a high-volume internet banking system

Vincent Coetzee, eBucks.com, vincent.coetzee@ebucks.com
Robert Walker, GemStone Systems, bob.walker@gemstone.com

Few large corporate organizations make the decision to use an Object Database Management System (ODBMS) when developing high volume transactional eCommerce web sites. This report examines the architecture used to power a website that encompasses banking, online shopping, and the management of a Customer Loyalty Currency called eBucks. This system proves that an ODBMS can be used in a high volume transactional system with great success. While the choice of this technology has many merits, there are drawbacks. These drawbacks are examined along with the solutions that have been used at eBucks to either solve or ameliorate them.

Old Code

Wednesday, 29 October – 13:30-15:00

Using AspectJ for Component Integration in Middleware

Adrian Colyer, IBM UK, adrian_colyer@uk.ibm.com
Ron Bodkin, New Aspects of Security, rbodkin@newaspects.com
Jim Hugunin, PARC, Jim.Hugunin@parc.com
Andrew Clement, IBM UK, andrew_clement@uk.ibm.com

This report discusses experiences applying and enhancing AspectJ for a middleware product line at IBM. The purpose of this effort was to apply Aspect Oriented Programming to cleanly separate components from their execution platforms, while still allowing them to take advantage of platform-specific facilities for aspects such as error handling, performance monitoring, and logging. It presents the evolution of the design, implementation, tools support, and approaches used to achieve organizational buy in.
Keywords: AspectJ, aspect oriented programming, middleware

Five years of framework building: lessons learned

Kurt Madsen, MetaTech, Inc., madsen@tampabay.rr.com

When developing large software systems, it is often difficult to foresee exactly which trade-offs are important, and which quality parameters will be of importance down the road. This paper reports experiences from a project in which a large application framework for B2B integration has been continuously developed and used over a five year period. The framework has been the foundation for a variety of different concrete applications; here we will report on our experiences from this endeavor.

Agile Regression Testing Using Record & Playback

Gerard Meszaros, ClearStream Consulting, gerard.meszaros@acm.org
Ralph Bohnet, ClearStream Consulting, ralph@clrstream.com
Jennitta Andrea, ClearStream Consulting, jennitta@clrstream.com

There are times when it is not practical to hand-script automated tests for an existing system before one starts to modify it (whether to refactor it to permit automated testing or to add new functionality). In these circumstances, the use of “record & playback” testing may be a viable alternative to hand-writing all the tests. This paper describes experiences using this approach and summarizes key learnings applicable to other projects.

Real-World Objects

Wednesday, 29 October – 15:30-17:00

Programming with Non-Heap Memory in RTSJ

Greg Bollella, Sun Microsystems Laboratories
Tim Canham, Jet Propulsion Laboratory, California Institute of Technology
Vanessa Carson, Jet Propulsion Laboratory, California Institute of Technology
Virgil Champlin, Jet Propulsion Laboratory, California Institute of Technology
Daniel Dvorak, Jet Propulsion Laboratory, California Institute of Technology
Brian Giovannoni, School of Computer Science, Carnegie Mellon University
Kenny Meyer, Jet Propulsion Laboratory, California Institute of Technology
Alex Murray, Jet Propulsion Laboratory, California Institute of Technology
Kirk Reinholtz, Jet Propulsion Laboratory, California Institute of Technology

The Real-Time Specification for Java (RTSJ) provides facilities for deterministic, real-time execution in a language that is otherwise subject to variable latencies in memory allocation and garbage collection. In particular, RTSJ introduces two kinds of non-heap memory area (ScopedMemory and ImmortalMemory) and a kind of real-time thread (NoHeapRealtimeThread) that, together, can satisfy very demanding timeliness requirements because they run without interference from the garbage collector. What new RTSJ programmers quickly discover, though, is that the RTSJ "assignment rules"—governing references from one kind of memory to another—force designers to think more carefully about how data flows among the components of a system. In particular, for the hard real-time portions of a system, the normal Java practice of freely passing around references and letting the garbage collector recognize when an object is no longer needed simply doesn't apply.

This report discusses two related design issues that all RTSJ users will face: how to explicitly manage non-heap memory and how to communicate information among components without violating RTSJ’s assignment rules. These issues are addressed from a practitioner’s viewpoint in the context of designing real-time control loops for driving and steering a 6-wheel Mars rover. The solution described here is termed “scoped memory scratchpads” and is believed to provide a good combination of Java-natural style and safety from programmer error. In this approach, transient data is allocated within a scoped memory area that is emptied later when all Runnables exeunt the memory area. Data that must be preserved across cyclic executions use memory pools, restricted so that all pool management is confined to a single component and is thus much easier to design and verify. Importantly, by maintaining a distinction between application-specific software and framework software, some of the details and discipline of using RTSJ can be hidden from application programmers.

The Parks PDA: A Handheld Device for Theme Park Guests in Squeak

Yoshiki Ohshima, Twin Sun, Inc., Yoshiki.Ohshima@acm.org
John Maloney, MIT Media Lab, JohnMaloney@earthlink.net
Andy Ogden, Strategy, Design, and Development Consulting, aogden@earthlink.net

The Parks PDA is a lightweight, handheld device for theme park guests that functions as a combination guidebook, map, and digital camera. Together with a small team of artists and designers, we created a prototype Parks PDA and content for a three hour guest experience, including a camera interface, a hyper-linked guide book, three games, an animal spotters guide, a cross-referenced map, animated movies with lip-synched sound, a ride reservation system, and more. Over 800 visitors to Disney's Animal Kingdom theme park tested the Parks PDA over a two week period.

Developing the software for this test posed a number of challenges. The processor and memory of the target device were slow, the screen was small, and we had only three months of development time.

We attacked these problems using Squeak, a highly-portable, open source Smalltalk implementation. We ported Squeak to the target device and used it to provide nearly bit-identical behavior across four different platforms. This supported a cross-platform development style that streamlined the production of both software and content. We created a tiny user interface and application framework for pen-based devices and implemented a simple card-stack media editor and player using it. We isolated and fixed several performance problems.

The project was completed on time and guest response was favorable. Looking back, we can identify ten aspects of Squeak that contributed to the success of the project. While we feel that Squeak was the ideal tool for this job, many of the key benefits of Squeak could be enjoyed using other object-oriented languages such as Java J2ME or Python, especially if the source code of the virtual machine is available.