Object Oriented Technology Saves the Day

This telephone gadget is an enormously successful invention; each new level of system that surrounds it has spawned radical innovations. Software is now a major part of all services and systems that manage them, especially the billing systems. Object-oriented programming and design is the next answer to the problem of getting reliable on-time software. But object-oriented technology (OOT) experiences the same birth pangs as every other new idea. It has taken until now for even so perceptive a mind as Fred Brooks, who wrote the defining philosophical work in our field, The Mythical Man-Month, to recognize that David Parnas was right. Programmers are most effective if shielded from, not exposed to, the innards of modules not their own. He is now convinced that information hiding, today often embodied in object-oriented programming, is the only way of raising the level of software design. Parnas' technique is robust under change and is more appropriate in a design-for-change philosophy.

Benefits and How to Reap Them

Using OOT has four broad benefits: the technique can manage complexity better than anything else available, it increases development speed and productivity, it lets reuse of systems become possible in a realistic way that was not practical before and it allows systems to be scaled-up. To reap these benefits, software technologies and techniques must be generally understood, tools and an infrastructure must be in place for programmers to work, and middle management must accept the new mind-set so that corporate culture and management processes are appropriate to this new method.

The first benefit, management of complexity, refers to problems such as computer-aided design, computer-integrated manufacturing and graphical user interfaces (GUI) that cannot be solved with relational databases alone. We need a mix of relational databases for report generation and object oriented databases (OODB) for scale. Now tools for objects require the existence of brokers to make management of this complexity possible. One supplier of OODB, Versant, provides an SQL-3 access method to help introduce OODBs gradually into existing systems. These interfaces are now becoming widely available. The second benefit, speedy development, is truly remarkable. Consider the history of technological advances that allow a programmer to expand the effect of a single line of written code as the number of machine instructions executed as a result. That relative productivity, the expansion factor, is the explosion of a written line of code into its actual machine code, expressed as a ratio. The higher the expansion factor, the less code a programmer has to write to complete a job. OOT expands programmer productivity by a factor of 3. Furthermore, the waterfall approach can take 6 to 18 months to achieve a demonstrable capability in the first release. If OOT is used, a working prototype can be created in one week. The third benefit, reuse, is a deeply frustrating and elusive goal. Literature and experience show that it takes 1.5 to 2.2 times the effort to write a software module so that it is a reusable asset. Reuse becomes profitable on the third use of a module. Data on the reuse of almost 3000 modules of NASA programs reveal that to reap the benefits of the extra original effort to make a module reusable, the module must be reused essentially unchanged. No change only costs 5 percent; the slightest change drives the cost up to 60 percent. That OOT intends to produce modules that are actual software products-designed, tested and with internal integrity-encourages the move toward reuse.

The fourth benefit, scaling, is critical. Today's software technology cannot support the scalability, robustness and reliability needed to manage heterogeneous networks, even when telecommunications management network (TMN) standards are followed. A large, feature-rich library of software components cannot be scaled because the families of data structure components implement the same abstraction. Every time a new feature is added, the number of components in the library doubles. Even small changes in TMN or any software can cause unacceptably large changes in system performance. Experienced software managers know that they test and retest every time they make the smallest change or risk system crashes and cranky customers. Most of what we hope to gain from OOT comes from module encapsulation plus the idea of pre-built libraries of modules or classes that are designed and tested for reuse.

Bjarne Stroustrup, inventor of C++, notes that moving to OOT is not painless, but it is worthwhile. He said that OOT forces developers to think about architecture and design from the beginning, not just as an afterthought. Stroustrup, in his soft-spoken but direct way, points out that every significant change carries risk:
"My number one reason to worry about Object-Oriented Design (OOD) is that middle managers will have to learn new tricks and techniques to manage development well. This is not easy. A development manager, say, is often in a position to get blame for whatever goes wrong, yet most of the credit goes to their people when things go well. This doesn't encourage risk-taking or innovation. Unless managers somehow find the time to get a basic understanding and a minimum level of comfort with OOT, it will seem only a risk, and token efforts will abound."

Real-life Dramas

In 1988, I ran a project in which changes were controlled on a Centrex system so people could have their telephone numbers follow them through moves. OOT was impressive there. Productivity increased 3 to 1. New features were added to the object-oriented sections with less effort and with fewer interface changes in the system. Accommodations to external changes in the object-oriented modules caused significantly fewer source lines to be modified than for similar changes in structured design modules. Redesign of selected subsystems using the object-oriented paradigm produced savings in maintenance. This was, however, a small project-just 10,000 lines of code, 400 function points and 20 people.

Two years later when there was a major effort to deploy OOT to many projects, problems in larger systems appeared. Legacy code had to be dealt with, the tools were primitive, the mind-set of relational databases was difficult to change, and many object classes tended to get lost. There was some stumbling and hesitation.

But the technology has improved enough today to produce systems that change the way of running a telephone network. Previously, the focus had been on the various hardware architectures. New OSSs based on OOT are different. They use an integrated operations support system platform that enables the efficient delivery, differentiation and billing of new high-quality services.

One project changed the paradigm of software development to so much that the original projections of 3,000 people and 36 months to delivery became invalid. It took 425 people 15 months to deliver the first release. There were 14 separate subsystems, of these, eight are new designs and six were encapsulations of previously built systems that were not redone. There were 9,000 function points, 22 modules, 47 system interfaces and 12 databases. The object classes were of 3 types: communications, system administration and user interfaces. There were 200 object classes and 400 objects. The communications object classes constituted 190,000 lines in a 3.5 million-line system. The discipline required to use OOT exposed a 40 percent redundancy in the design specifications and allowed the code to be pared down to elegance. The software became a thing of beauty.

Production efficiency was not the whole story of OOT in this project. Even more significant is the clear conclusion that the database is the key to system integrity. Any meaningful concept of integration must revolve around the objects the systems use, and systems are integrated to the degree that they use the same objects.

Lessons Learned

Some valuable lessons were learned along the way. Primary was the critical attention to design. Both top-down structuring and bottom-up design were important to finding out where object classes were. The preliminary design activities that helped determine the object classes were the development of business scenarios that were analyzed with class, responsibility, and collaborator (CRC) cards. These cards revealed affinities among modules that allowed them to be generalized into object classes.

A guiding principle from our previous troubles was that the object class libraries should be very small, 0.5 percent of the number of function points, because we had no tools to keep track of large numbers of classes. Earlier experiences showed programmers tended to develop unique dialects that became difficult to maintain. The details of the object classes caused problems at boundary conditions. For example, when the attributes of data being passed were slightly different, modules were not initialized properly. There was considerable churn on attributes. Ultimately, Fred Brooks' realization of the major paradigm shift was made real to us also: the greater the isolation of each object, the greater its power.

OODBs are critical to performance in using objects because new tools make it so much easier than using a translator like PERSISTANCE to go into relational databases. Going straight into an OODB has neither indirection nor possibility of error. Projections are that the top 10 object classes will have to be moved to an OODB because of performance considerations.

Recovery is a whole new ballgame with object classes. Because the object contains the state of the previous transaction, developers can use a fast-forward approach. The recovery system does not lag behind the online system.

Transition Considerations

There are many ways to migrate to OOT. All require some degree of training and learning by experience. The two approaches of seeding and sandbox have worked well. Project managers prefer seeding when project members need to start developing products quickly. Experts in OOT are recruited either as consultants or regular staff. As these experts lead the OOT activities, they also work at bringing other project members up to speed. The sandbox, or learning through doing, approach gives programmers initial training and then allows them to explore concepts and C++ and rely on experts to review the work before they move into production development. Project managers used this method early on, when there was a shortage of experts. Either way, the point is to change the way project members look at a problem. These are some specific suggestions (ten commandments, in fact) for making a graceful transition to OOT: 1. Pilot tools and processes before widely deploying them.
2. Have OOT consultants jumpstart the first job.
3. Invest $10,000 for tools, equipment and 6 months in training per object-oriented designer.
4. Maintain no more than 20 percent of the staff as object-oriented architects; they alone should create object classes.
5. Limit the number of object classes to 0.5 percent of the project's function points; no more than one-third of those classes should have an inheritance of greater than three.
6. Spend 30 percent of the total development cycle in design; with heavy emphasis on object modeling. Be especially concerned with object generality.
7. Model performance as soon as design starts. Calibrate and analyze the model frequently.
8. Invest heavily in unit test drivers and design tests for feature and data relationships.
9. Never assign work by class or methods; assign it by feature teams. Don't let the tool move you one more level of abstraction from the problem domain.
10. Expect productivity to break even on the first release; afterward expect gains of 3 to 1.

Where Does It Fit and Why?

Where does OOT belong in anyone's life? Certainly it doesn't belong on a desktop where there is no need for scalability or performing operations on large data entities. It is needed on servers. PCs need only vendor software and user programs. A workstation could benefit from some reusable software and perhaps some object-oriented design. The proportions change as the size of the server increases. Application servers that have replaced departmental databases could benefit from professional engineering. The large data servers require the most engineering. As servers handle more corporate data, the investment in software professionals is well spent. Data is the most important corporate asset; reliability, protection and confidentiality are crucial.

In a distributed system, data appears in many places. For example, telephone companies have huge files for billing information. Customer care workers need access to these files. Copies are downloaded to their PCs. Unless specific provisions are in place, customer databases can be changed without notifying the related databases. Errors creep in; the error rate in the database containing information about your telephones and their connection to a central office is about 10 percent. The error rate of maintenance databases can be worse (30 percent). Changing the telephone equipment instead of updating the databases recording the change is easier by a factor of 2.

People are not deliberately slovenly in changing or updating data, but the cost of keeping things in sync has proved intractably high and the methods unacceptably slow. An example of one technique is the "two-phase commit," in which the changing database and the updated database must commit to the change before the data can be accessed again. To keep data uncorrupted, mechanisms that provide logical updates are required in supporting software systems. None of these mechanisms comes without expensive tradeoffs because in distributed relational databases, all data references are changed when the data is changed, not when it is used.

In real life, no more than approximately 5 percent of a database is accessed at once. OODBs take advantage of this fact to do updates more efficiently. An action sits in memory until its data is actually accessed, and only then are the universal updates made to all references. If the data is never accessed, it does not need to be updated. In the worst case, 5 percent of the database is updated instead of 100 percent, the costs hold up all system transactions while the update happens. Whatever the technique, the design of the logical update routes is a major design consideration.

Conclusion

Object-oriented technology is a concept-and-problem approach that is advancing software design. Problems of great complexity can now be managed. System development can be more efficient. Data integrity can be ensured. When this philosophy is ultimately coupled with large-scale reuse of modules, we will look at distributed relational databases like we look at Model T Fords.

Larry Bernstein is a recognized expert in network management, software and technology conversion. He is president of the National Software Council and is and consultant through his firm Have Laptop Will Travel. Larry is the Chief Technical Officer of Telecommunications Intellectual Software building software systems for managing telephone services. He can be reached at lbernstein@worldnet.att.net.