Object-Oriented Design

By Mike Bray, Lockheed-Martin Ground Systems

Object-oriented design (OOD) is concerned with developing an object-oriented model of a software system to implement the identified requirements. Many OOD methods have been described since the late 1980s. The most popular OOD methods include Booch, Buhr, Wasserman, and the HOOD method developed by the European Space Agency. OOD can yield the following benefits: maintainability through simplified mapping to the problem domain, which provides for less analysis effort, less complexity in system design, and easier verification by the user; reusability of the design artifacts, which saves time and costs; and productivity gains through direct mapping to features of Object-Oriented Programming Languages.

Technical Detail

OOD builds on the products developed during Object-Oriented Analysis (OOA) by refining candidate objects into classes, defining message protocols for all objects, defining data structures and procedures, and mapping these into an object-oriented programming language (OOPL). Several OOD methods (Booch, Shlaer-Mellor, Buhr, Rumbaugh) describe these operations on objects, although none is an accepted industry standard. Analysis and design are closer to each other in the object-oriented approach than in structured analysis and design. For this reason, similar notations are often used during analysis and the early stages of design. However, OOD requires the specification of concepts nonexistent in analysis, such as the types of the attributes of a class, or the logic of its methods.

Design can be thought of in two phases. The first, called high-level design, deals with the decomposition of the system into large, complex objects. The second phase is called low-level design. In this phase, attributes and methods are specified at the level of individual objects. This is also where a project can realize most of the reuse of object-oriented products, since it is possible to guide the design so that lower-level objects correspond exactly to those in existing object libraries or to develop objects with reuse potential. As in OOA, the OOD artifacts are represented using CASE tools with object-oriented terminology.

Usage Considerations

OOD techniques are useful for development of large complex systems. AT&T Bell Labs used OOD and realized the benefits of reduced product development time and increased reuse of both code and analysis/design artifacts on a large project called the Call Attempt Data Collection System (CADCS). This large project consisted of over 350,000 lines of C++ code that ran on a central processor with over 100 remote systems distributed across the United States. During the development of two releases of the CADCS they found that use of the OOD techniques resulted in a 30% reduction in development time and a 20% reduction in development staff effort as compared to similarly sized projects using traditional software development techniques. However, these successes were realized only after thorough training and completion of three- to six-month pilot projects by their development staff.

Experiences from other organizations show costly learning curves and few productivity improvements without thoroughly-trained designers and developers. Additionally, OOD methods must be adapted to the project since each method contains object models that may be too costly, or provide little value, for use on a specific project.

The maximum impact from OOD is achieved when used with the goal of designing reusable software systems. For objects without significant reuse potential, OOD techniques were more costly than traditional software development methodologies. This was because of the costs associated with developing objects and the software to implement these objects for a one-time use.

Maturity

Many OOD methods have been used in industry since the late 1980s. OOD has been used worldwide in many commercial, Department of Defense (DoD), and government applications. There exists a wealth of documentation and training courses for each of the various OOD methods, along with commercially-available CASE tools with object-oriented extensions that support these OOD methods.

Costs and Limitations

One reason for the mixed success reviews on OOD techniques is that the use of this technology requires a corporate commitment to formal training in the OOD methods and the purchase of CASE tools with capabilities that support these methods. The method of training that produces the best results is to initiate pilot projects, conduct formal classes, employ OOD mentors, and conduct team reviews to train properly both the analysis and development staff as well as the program management team. There are few, if any, reported successes using OOD methods on the first application without this type of training program. Projects with initial and continuing OOD training programs realize that the benefits of this technology depend upon the training and experience levels of their staffs.

Dependencies

The use of OOD technology requires the development of object requirements using OOA techniques, and CASE tools to support both the drawing of objects and the description of the relationships between objects. Also, the final steps of OOD, representing classes and objects in programming constructs, are dependent on the object-oriented programming language (OOPL) chosen. For example, if the OOPL is Ada 95, a package-based view of the implementation should be used; if C++ is the OOPL, then a class-based view should be used. These different views require different technical design decisions and implementation considerations.

Alternatives

An alternative technology that can be used for developing a model of a software system design to implement the identified requirements is a traditional design approach such as Yourdon and Constantine's Structured Design. This method, used successfully for many different types of applications, is centered around design of the required functions of a system and does not lend itself to object orientation.

Complementary Technologies

Combining object-oriented methods with >Cleanroom (with its emphasis on rigor, formalisms, and reliability) can define a process capable of producing results that are reusable, predictable, and high-quality. Thus, object-oriented methods can be used for front-end domain analysis and design, and Cleanroom can be used for life-cycle application engineering.