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.
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.
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%.
Participants should be ready to learn from others' experiences.