OOPSLA 2002



Tracks
Technical Program
Tutorials
Workshops
DesignFest
Educators' Symposium
Doctoral Symposium
Demonstrations
Posters
Student Research
Competition

Student Volunteers
Special Events
Exhibits
Housing Information
Registration Information
Transportation

Thursday, 7 November – 15:30-17:00

Session C

In the Trenches: Tough Problems

Chair: Jeffrey Wills
Valparaiso University

A Common Multi-Platform Hardware Object Model

Joseph Armstrong
IBM Server Group, jdarmstr@us.ibm.com
Astrid Kreissig
IBM Server Group, kloss@us.ibm.com

About 5 years ago one group in IBM's high end server system started a redesign of its hardware access layer. Flexibility for any kind of configuration and hardware was the main goal for the design, to allow for rapid bringup changes and changing hardware packaging. Object-oriented design was the obvious choice. About 2 years ago another group in IBM's middle and low end server systems started a redesign of their hardware access layer. The same basic objectives as the high end systems applied. Additionally the middle and low end systems group was continuing the consolidation of its servers to one eServer with a common service processor. Both hardware platforms are multi-processor systems supporting tera-bytes of I/O and a multitude of operating systems from z/OS and OS/400 to AIX and Linux.

Everything cried for reuse.

This report is about the challenges of a major object-oriented design affecting many components and attempting code reuse between different projects on different hardware in different organizations and different development sites including different countries. We will list the goals we had, where we are now, what proved to be good concepts and what the roadblocks were. The report ends with an outlook on what we will approach next.

eXtreme Embedded - A report from the Front Line

Gary Mueller
Consultant, garymueller@qwest.net
Janet Borzuchowski
Storage Technology Corporation, janetborzuchowsk@qwest.net

Many embedded development environments are stuck somewhere in the backwash of software technology. Structured programming practices, with the artifacts of those methodologies liberally scattered about, are the norm in these environments. The world has changed since structured methodologies first emerged, with shorter and shorter market windows and increasingly sophisticated customers demanding more and more capabilities at lower and lower cost. Embedded system development must also adapt to these market imperatives to stay competitive. This report describes the challenges, obstacles, and successes encountered in applying eXtreme Programming on an embedded legacy product with a team of seasoned, veteran C programmers.

Transformation of an Application Data Layer

Will Loew-Blosser
Cargill, Inc., will_loew-blosser@cargill.com

Changing a fundamental interface in a large application is typically considered impractical because of high risks and costs. This report demonstrates that with careful use of tools and testing, risks and costs can be significantly reduced. A very large Smalltalk application was developed at Cargill. About 2,000 classes in this application interacted with a data access framework. The framework dynamically performed runtime mapping of object attributes to data table columns. Analysis showed that although dynamic look up consumed 40% of execution time, it was unnecessary.

To improve performance, we decided to replace dynamic lookup with an explicit object to database mapping scheme. Our solution involved changing the data framework as well as the application classes. The challenge was how to change 2000 classes in a systematic manner.

Normally, refactoring consists of a series of small safe steps that improve design while preserving behavior. Instead of performing many small transformations, we used the facilities in Brant and Roberts' Smalltalk Refactoring browser to make more significant program transformations. Using the facilities in Smalltalk Refactoring Browser we defined our own program transformation rules and then applied them.

This allowed us to systematically make 16,000 changes almost bug free. We further reduced our risk by rigorously testing our changes using Beck's S-Unit tool. After these transformations, execution time spent in the data access framework was reduced from 40% to less than 2%.