In review
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
[Baudoin
96]. 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 [Baudoin
96].
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) (see Object-Oriented
Programming Languages). 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.
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
[Kamath
93]. However, these successes were realized only after
thorough training and completion of three- to six-month pilot
projects by their development staff [Kamath
93].
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
[Malan
95].
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 [Maring
96].
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.
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 [Kamath
93]. There are few, if any, reported successes using OOD
methods on the first application without this type of training
program [Maring
96]. 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.
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.
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 [Yourdon
79]. 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.
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 [Ett
96].
This technology is classified under the following categories.
Select a category for a list of related topics.
|
Name of technology
|
Object-Oriented Design
|
|
Application category
|
Detailed
Design (AP.1.3.5)
Reengineering
(AP.1.9.5)
|
|
Quality measures category
|
Maintainability
(QM.3.1)
Reusability
(QM.4.4)
|
|
Computing reviews category
|
Object-Oriented Programming (D.1.5)
Software Engineering Design (D.2.10)
|
|
[Baudoin 96]
|
Baudoin, Claude & Hollowell, Glenn.
Realizing the Object-Oriented Lifecycle. Upper
Saddle River, NJ: Prentice Hall, 1996.
|
|
[Ett 96]
|
Ett, William & Trammell, Carmen. A
Guide to Integration of Object-Oriented Methods and
Cleanroom Software Engineering [online].
Originally available WWW
<URL:
http://www.asset.com/stars/loral/cleanroom/oo/guidhome.htm>
(1996).
|
|
[Kamath 93]
|
Kamath, Y. H.; Smilan, R. E.; &
Smith, J. G. "Reaping Benefits With Object-Oriented
Technology." AT&T Technical Journal 72, 5
(September/October 1993): 14-24.
|
|
[Malan 95]
|
Malan, R.; Coleman, D.; & Letsinger,
R. "Lessons Learned from the Experiences of Leading-Edge
Object Technology Projects in Hewlett-Packard," 33-46.
Proceedings of Tenth Annual Conference on
Object-Oriented Programming Systems Languages and
Applications. Austin, TX, October 15-19, 1995. Palo
Alto, CA: Hewlett-Packard, 1995.
|
|
[Maring 96]
|
Maring, B. "Object-Oriented Development
of Large Applications." IEEE Software 13, 3 (May
1996): 33-40.
|
|
[Yourdon 79]
|
Yourdon, E. & Constantine, L.
Structured Design. Englewood Cliffs, NJ: Prentice
Hall, 1979.
|
Mike Bray, Lockheed-Martin Ground Systems
27 Oct 97: updated URL for [ETT 96]
10 Jan 97: original
