Unit ii oo design 9

20
UNIT II OO DESIGN 9
Object model – Classes and objects – Object oriented analysis – Key abstractions and
mechanisms – Object oriented design – Identifying design elements – Detailed design –
Case studies.
OBJECT MODEL
Object-oriented technology is built on a sound engineering foundation, whose elements we
collectively call the object model of development or simply the object model. The object model
encompasses the principles of abstraction, encapsulation, modularity, hierarchy, typing,
concurrency, and persistence. By themselves, none of these principles are new. What is
important about the object model is that these elements are brought together in a synergistic way.
Let there be no doubt that object-oriented analysis and design is fundamentally different than
traditional structured design approaches: It requires a different way of thinking about
decomposition, and it produces software architectures that are largely outside the realm of the
structured design culture.
The Evolution of the Object Model
Object-oriented development did not spontaneously generate itself from the ashes of the
uncounted failed software projects that used earlier technologies. It is not a radical departure
from earlier approaches. Indeed, it is founded in the best ideas from prior technologies. In this
section we will examine the evolution of the tools of our profession to help us understand the
foundation and emergence of object oriented technology.
As we look back on the relatively brief yet colorful history of software engineering, we cannot
help but notice two sweeping trends:
1. The shift in focus from programming-in-the-small to programming-in-the large
2. The evolution of high-order programming languages
Most new industrial-strength software systems are larger and more complex than their
predecessors were even just a few years ago. This growth in complexity has prompted a
significant amount of useful applied research in software engineering, particularly with regard to
decomposition, abstraction, and hierarchy. The development of more expressive programming
languages has complemented these advances.

21
The Generations of Programming Languages
Wegner has classified some of the more popular high-order programming languages in
generations arranged according to the language features they first introduced [2]. (By no means
is this an exhaustive list of all programming languages.)
■ First-generation languages (1954–1958)
FORTRAN I Mathematical expressions
ALGOL 58 Mathematical expressions
Flowmatic Mathematical expressions
IPL V Mathematical expressions
■ Second-generation languages (1959–1961)
FORTRAN II Subroutines, separate compilation
ALGOL 60 Block structure, data types
COBOL Data description, file handling
Lisp List processing, pointers, garbage collection
■ Third-generation languages (1962–1970)
PL/1 FORTRAN + ALGOL + COBOL
ALGOL 68 Rigorous successor to ALGOL 60
Pascal Simple successor to ALGOL 60
Simula Classes, data abstraction
■ The generation gap (1970–1980)
Many different languages were invented, but few endured. However, the following are worth
noting:
C-> Efficient; small executables
FORTRAN ->77 ANSI standardization
Let’s expand on Wegner’s categories.
■ Object-orientation boom (1980–1990, but few languages survive)

22
Smalltalk-> 80 Pure object-oriented language
C++ ->Derived from C and Simula
Ada83 ->Strong typing; heavy Pascal influence
Eiffel ->Derived from Ada and Simula
■ Emergence of frameworks (1990–today)
Much language activity, revisions, and standardization have occurred, leading to programming
frameworks.
Visual Basic-> Eased development of the graphical user interface(GUI) for Windows
applications
Java ->Successor to Oak; designed for portability
Python-> Object-oriented scripting language
J2EE ->Java-based framework for enterprise computing
.NET-> Microsoft’s object-based framework
Visual C#-> Java competitor for the Microsoft .NET Framework
Visual Basic .NET ->Visual Basic for the Microsoft .NET Framework
In successive generations, the kind of abstraction mechanism each language supported changed.
First-generation languages were used primarily for scientific and engineering applications, and
the vocabulary of this problem domain was almost entirely mathematics. Languages such as
FORTRAN I were thus developed to allow the programmer to write mathematical formulas,
thereby freeing the programmer from some of the intricacies of assembly or machine language.
This first generation of high-order programming languages therefore represented a step closer to
the problem space and a step further away from the underlying machine. Among second-
generation languages, the emphasis was on algorithmic abstractions.
By this time, machines were becoming more and more powerful, and the economics of the
computer industry meant that more kinds of problems could be automated, especially for
business applications. Now, the focus was largely on telling the machine what to do: read these
personnel records first, sort them next, and then print this report. Again, this new generation of
high-order programming languages moved us a step closer to the problem space and further
away from the underlying machine.
By the late 1960s, especially with the advent of transistors and then integrated circuit technology,
the cost of computer hardware had dropped dramatically, yet processing capacity had grown
almost exponentially. Larger problems could now be solved, but these demanded the
manipulation of more kinds of data. Thus, third generation languages such as ALGOL 60 and,

23
later, Pascal evolved with support for data abstraction. Now a programmer could describe the
meaning of related kinds of data (their type) and let the programming language enforce these
design decisions. This generation of high-order programming languages again moved our
software a step closer to the problem domain and further away from the underlying machine.
The 1970s provided us with a frenzy of activity in programming language research, resulting in
the creation of literally a couple of thousand different programming languages and dialects. To a
large extent, the drive to write larger and larger programs highlighted the inadequacies of earlier
languages; thus, many new language mechanisms were developed to address these limitations.
Few of these languages survived (have you seen a recent textbook on the languages Fred, Chaos,
or Tranquil?); however, many of the concepts that they introduced found their way into
successors of earlier languages.
What is of the greatest interest to us is the class of languages we call object-based and object-
oriented. Object-based and object-oriented programming languages best support the object-
oriented decomposition of software. The number of these languages (and the number of
“objectified” variants of existing languages) boomed in the 1980s and early 1990s. Since 1990 a
few languages have emerged as mainstream OO languages with the backing of commercial
programming tool vendors (e.g., Java, C++). The emergence of programming frameworks (e.g.,
J2EE, .NET), which provide a tremendous amount of support to the programmer by offering
components and services that simplify the common and often mundane programming tasks, has
greatly boosted productivity and demonstrated the elusive promise of component reuse.
The Topology of First- and Early Second- Generation Programming Languages
Let’s consider the structure of each
generation of programming languages. In
Figure 2–1, we see the topology of most
first- and early second-generation
programming languages. By topology, we
mean the basic physical building blocks of
the language and how those parts can be
connected. In this figure, we see that for
languages such as FORTRAN and
COBOL, the basic physical building block
of all applications is the subprogram (or
the paragraph, for those who speak
COBOL).
Applications written in these languages exhibit a relatively flat physical structure, consisting
only of global data and subprograms. The arrows in this figure indicate dependencies of the
subprograms on various data. During design, one can logically separate different kinds of data
from one another, but there is little in these languages that can enforce these design decisions. An
error in one part of a program can have a devastating ripple effect across the rest of the system
because the global data structures are exposed for all subprograms to see.

24
When modifications are made to a large system, it is difficult to maintain the integrity of the
original design. Often, entropy sets in: After even a short period of maintenance, a program
written in one of these languages usually contains a tremendous amount of cross-coupling among
subprograms, implied meanings of data, and twisted flows of control, thus threatening the
reliability of the entire system and certainly reducing the overall clarity of the solution.
The Topology of Late Second- and Early
Third-Generation Programming Languages
By the mid-1960s, programs were finally being recognized as important intermediate points
between the problem and the computer [3]. “The first software abstraction, now called the
‘procedural’ abstraction, grew directly out of this pragmatic view of software. . . . Subprograms
were invented prior to 1950, but were not fully appreciated as abstractions at the time. . . .
Instead, they were originally seen as labor-saving devices. Very quickly though, subprograms
were appreciated as a way to abstract program functions” [4].
The realization that subprograms could
serve as an abstraction mechanism had
three important consequences. First,
languages were invented that supported a
variety of parameter-passing mechanisms.
Second, the foundations of structured
programming were laid, manifesting
themselves in language support for the
nesting of subprograms and the
development of theories regarding control
structures and the scope and visibility of
declarations. Third, structured design methods emerged, offering guidance to designers trying to
build large systems using subprograms as basic physical building blocks. Thus, it is not
surprising, as Figure 2–2 shows, that the topology of late second- and early third-generation
languages is largely a variation on the theme of earlier generations. This topology addresses
some of the inadequacies of earlier languages, namely, the need to have greater control over
algorithmic abstractions, but it still fails to address the problems of programming-in-the-large
and data design.
The Topology of Late Third-Generation
Programming Languages
Starting with FORTRAN II, and appearing
in most late third-generation program
languages, another important structuring
mechanism evolved to address the
growing issues of programming-in-the-
large. Larger programming projects meant
larger development teams, and thus the

25
need to develop different parts of the same program independently. The answer to this need was
the separately compiled module, which in its early conception was little more than an arbitrary
container for data and subprograms, as Figure 2–3 shows. Modules were rarely recognized as an
important abstraction mechanism; in practice they were used simply to group subprograms that
were most likely to change together.
Most languages of this generation, while supporting some sort of modular structure, had few
rules that required semantic consistency among module interfaces. A developer writing a
subprogram for one module might assume that it would be called with three different parameters:
a floating-point number, an array of ten elements, and an integer representing a Boolean flag. In
another module, a call to this subprogra m might incorrectly use actual parameters that violated
these assumptions: an integer, an array of five elements, and a negative number. Similarly, one
module might use a block of common data that it assumed as its own, and another module might
violate these assumptions by directly manipulating this data. Unfortunately, because most of
these languages had dismal support for data abstraction and strong typing, such errors could be
detected only during execution of the program.
The Topology of Object-Based and Object- Oriented Programming Languages
Data abstraction is important to
mastering complexity. “The nature
of abstractions that may be achieved
through the use of procedures is
well suited to the description of
abstract operations, but is not
particularly well suited to the
description of abstract objects. This
is a serious drawback, for in many
applications, the complexity of the
data objects to be manipulated
contributes substantially to the
overall complexity of the problem”
[5]. This realization had two
important consequences. First, data-driven design methods emerged, which provided a
disciplined approach to the problems of doing data abstraction in algorithmically oriented
languages. Second, theories regarding the concept of a type appeared, which eventually found
their realization in languages such as Pascal. The natural conclusion of these ideas first appeared
in the language Simula and was improved upon, resulting in the development of several
languages such as Smalltalk, Object Pascal, C++, Ada, Eiffel, and Java. For reasons that we will
explain shortly, these languages are called object-based or object-oriented. Figure 2–4 illustrates
the topology of such languages for small to moderate-sized applications.
The physical building block in such languages is the module, which represents a logical
collection of classes and objects instead of subprograms, as in earlier languages. To state it
another way, “If procedures and functions are verbs and pieces of data are nouns, a procedure-
oriented program is organized around verbs while an object-oriented program is organized
around nouns” [6]. For this reason, the physical structure of a small to moderate-sized object-

26
oriented application appears as a graph, not as a tree, which is typical of algorithmically oriented
languages.
Additionally, there is little or no
global data. Instead, data and
operations are united in such a way
that the fundamental logical building
blocks of our systems are no longer
algorithms, but instead are classes
and objects. By now we have
progressed beyond programming-in-
the-large and must cope with
programming-in-the-colossal. For
very complex systems, we find that
classes, objects, and modules provide
an essential yet insufficient means of
abstraction. Fortunately, the object
model scales up. In large systems, we
find clusters of abstractions built in
layers on top of one another. At any
given level of abstraction, we find
meaningful collections of objects that
collaborate to achieve some higher-
level behavior. If we look inside any given cluster to view its implementation, we unveil yet
another set of cooperative abstractions. This is exactly the organization of complexity described
in Chapter 1; this topology is shown in Figure 2–5.
Foundations of the Object Model
Structured design methods evolved to guide developers who were trying to build complex
systems using algorithms as their fundamental building blocks. Similarly, object-oriented design
methods have evolved to help developers exploit the expressive power of object-based and
object-oriented programming languages, using the class and object as basic building blocks.
Actually, the object model has been influenced by a number of factors, not just object-oriented
programming. Indeed, as further discussed in the sidebar, Foundations— The Object Model, the
object model has proven to be a unifying concept in computer science, applicable not just to
programming languages but also to the design of user interfaces, databases, and even computer
architectures. The reason for this widespread appeal is simply that an object orientation helps us
to cope with the complexity inherent in many different kinds of systems.
Object-oriented analysis and design thus represents an evolutionary development, not a
revolutionary one; it does not break with advances from the past but builds on proven ones.
Unfortunately, most programmers are not rigorously trained in OOAD. Certainly, many good
engineers have developed and deployed countless useful software systems using structured
design techniques. However, there are limits to the amount of complexity we can handle using
only algorithmic decomposition; thus we must turn to object-oriented decomposition.
Furthermore, if we try to use languages such as C++ and Java as if they were only traditional,

27
algorithmically oriented languages, we not only miss the power available to us, but we usually
end up worse off than if we had used an older language such as C or Pascal. Give a power drill to
a carpenter who knows nothing about electricity, and he would use it as a hammer. He will end
up bending quite a few nails and smashing several fingers, for a power drill makes a lousy
hammer.
Because the object model derives from so many disparate sources, it has unfortunately been
accompanied by a muddle of terminology. A Smalltalk programmer uses methods, a C++
programmer uses virtual member functions, and a CLOS programmer uses generic functions.
Object Pascal programmer talks of a type coercion; an Ada programmer calls the same thing a
type conversion; a C# or Java programmer would use a cast. To minimize the confusion, let’s
define what is object-oriented and what is not. The phrase object-oriented “has been bandied
about with carefree abandon with much the same reverence accorded ‘motherhood,’ ‘apple pie,’
and ‘structured programming’”[ 7]. What we can agree on is that the concept of an object is
central to anything object-oriented. In the previous chapter, we informally defined an object as a
tangible entity that exhibits some well-defined behavior. Stefik and Bobrow define objects as
“entities that combine the properties of procedures and data since they perform computations and
save local state” [8]. Defining objects as entities begs the question somewhat, but the basic
concept here is that objects serve to unify the ideas of algorithmic and data abstraction. Jones
further clarifies this term by noting that “in the object model, emphasis is placed on crisply
characterizing the components of the physical or abstract system to be modeled by a
programmed system. . . . Objects have a certain ‘integrity’ which should not—in fact, cannot—
are violated. An object can only change state, behave, be manipulated, or stand in relation to
other objects in ways appropriate to that object. Stated differently, there exist invariant properties
that characterize an object and its behavior. An elevator, for example, is characterized by
invariant properties including [that] it only travels up and down inside its shaft. Any elevator
simulation must incorporate these invariants, for they are integral to the notion of an elevator”
[32].
Object-Oriented Programming
What, then, is object-oriented programming (OOP)? We define it as follows: Object-oriented
programming is a method of implementation in which programs are organized as cooperative
collections of objects, each of which represents an instance of some class, and whose classes are
all members of a hierarchy of classes united via inheritance relationships.
There are three important parts to this definition: (1) Object-oriented programming uses objects,
not algorithms, as its fundamental logical building blocks (the “part of” hierarchy we introduced
in Chapter 1); (2) each object is an instance of some class; and (3) classes may be related to one
another via inheritance relationships (the “is a” hierarchy we spoke of in Chapter 1). A program
may appear to be object-oriented, but if any of these elements is missing, it is not an object-
oriented program. Specifically, programming without inheritance is distinctly not object
oriented; that would merely be programming with abstract data types. By this definition, some
languages are object-oriented, and some are not. Stroustrup suggests that “if the term ‘object-
oriented language’ means anything, it must mean a language that has mechanisms that support
the object-oriented style of programming well. . . . A language supports a programming style
well if it provides facilities that make it convenient to use that style. A language does not support

28
a technique if it takes exceptional effort or skill to write such programs; in that case, the language
merely enables programmers to use the techniques” [33]. From a theoretical perspective, one can
fake object-oriented programming in non object- oriented programming languages like Pascal
and even COBOL or assembly language, but it is horribly ungainly to do so. Cardelli and
Wegner thus say: [A] language is object-oriented if and only if it satisfies the following
requirements:
■ It supports objects that are data abstractions with an interface of named operations and a
hidden local state.
■ Objects have an associated type [class].
■ Types [classes] may inherit attributes from supertypes [superclasses]. [34]
For a language to support inheritance means that it is possible to express “is a” relationships
among types, for example, a red rose is a kind of flower, and a flower is a kind of plant. If a
language does not provide direct support for inheritance, then it is not object-oriented. Cardelli
and Wegner distinguish such languages by calling them object-based rather than object-oriented.
Under this definition, Smalltalk, Object Pascal, C++, Eiffel, CLOS, C#, and Java are all object-
oriented, and Ada83 is object-based (support for object orientation was later added to Ada95).
However, since objects and classes are elements of both kinds of languages, it is both possible
and highly desirable for us to use object oriented design methods for both object-based and
object-oriented programming languages.
Object-Oriented Design
The emphasis in programming methods is primarily on the proper and effective use of particular
language mechanisms. By contrast, design methods emphasize the proper and effective
structuring of a complex system. What, then, is object oriented design (OOD)? We suggest the
following: Object-oriented design is a method of design encompassing the process of object
oriented decomposition and a notation for depicting both logical and physical as well as static
and dynamic models of the system under design.
There are two important parts to this definition: object-oriented design (1) leads to an object-
oriented decomposition and (2) uses different notations to express different models of the logical
(class and object structure) and physical (module and process architecture) design of a system, in
addition to the static and dynamic aspects of the system.
The support for object-oriented decomposition is what makes object-oriented design quite
different from structured design: The former uses class and object abstractions to logically
structure systems, and the latter uses algorithmic abstractions. We will use the term object-
oriented design to refer to any method that leads to an object-oriented decomposition.
Object-Oriented Analysis
The object model has influenced even earlier phases of the software development lifecycle.
Traditional structured analysis techniques, best typified by the work of DeMarco [35], Yourdon
[36], and Gane and Sarson [37], with real-time extensions by Ward and Mellor [38] and by

29
Hatley and Pirbhai [39], focus on the flow of data within a system. Object-oriented analysis
(OOA) emphasizes the building of real-world models, using an object-oriented view of the
world: Object-oriented analysis is a method of analysis that examines requirements from the
perspective of the classes and objects found in the vocabulary of the problem domain.
How are OOA, OOD, and OOP related? Basically, the products of object-oriented analysis serve
as the models from which we may start an object-oriented design; the products of object-oriented
design can then be used as blueprints for completely implementing a system using object-
oriented programming methods.
2.3 Elements of the Object Model
Jenkins and Glasgow observe that “most programmers work in one language and use only one
programming style. They program in a paradigm enforced by the language they use. Frequently,
they have not been exposed to alternate ways of thinking about a problem, and hence have
difficulty in seeing the advantage of choosing a style more appropriate to the problem at hand”
[40]. Bobrow and Stefik define a programming style as “a way of organizing programs on the
basis of some conceptual model of programming and an appropriate language to make programs
written in the style clear” [41]. They further suggest that there are five main kinds of
programming styles, listed here with the kinds of abstractions they employ:
1. Procedure-oriented Algorithms
2. Object-oriented Classes and objects
3. Logic-oriented Goals, often expressed in a predicate calculus
4. Rule-oriented If–then rules
5. Constraint-oriented Invariant relationships
There is no single programming style that is best for all kinds of applications. For example, rule-
oriented programming would be best suited for the design of a knowledge base, and procedure-
oriented programming would be best for the design of computation-intense operations. From our
experience, the object-oriented style is best suited to the broadest set of applications; indeed, this
programming paradigm often serves as the architectural framework in which we employ other
paradigms. Each of these styles of programming is based on its own conceptual framework. Each
requires a different mindset, a different way of thinking about the problem. For all things object-
oriented, the conceptual framework is the object model. There are four major elements of this
model:
1. Abstraction
2. Encapsulation
3. Modularity
4. Hierarchy

30
By major, we mean that a model without any one of these elements is not object oriented.
Without this conceptual framework, you may be programming in a language such as Smalltalk,
Object Pascal, C++, Eiffel, or Ada, but your design is going to smell like a FORTRAN, Pascal,
or C application. You will have missed out on or otherwise abused the expressive power of the
object-oriented language you are using for implementation. More importantly, you are not likely
to have mastered the complexity of the problem at hand.
The Meaning of Abstraction
Abstraction is one of the fundamental ways that we as humans cope with complexity. Dahl,
Dijkstra, and Hoare suggest that “abstraction arises from a recognition of similarities between
certain objects, situations, or processes in the real world, and the decision to concentrate upon
these similarities and to ignore for the time being the differences” [42]. Shaw defines an
abstraction as “a simplified description, or specification, of a system that emphasizes some of the
system’s details or properties while suppressing others. A good abstraction is one that
emphasizes details that are significant to the reader or user and suppresses details that are, at
least for the moment, immaterial or diversionary” [43]. Berzins, Gray, and Naumann recommend
that “a concept qualifies as an abstraction only if it can be described, understood, and analyzed
independently of the mechanism that will eventually be used to realize it” [44]. Combining these
different viewpoints, we define an abstraction as follows:
An abstraction denotes the essential characteristics of an object that distinguish it from all other
kinds of objects and thus provide crisply defined conceptual boundaries, relative to the
perspective of the viewer. An abstraction focuses on the outside view of an object and so serves
to separate an object’s essential behavior from its implementation. Abelson and Sussman call this
behavior/implementation division an abstraction barrier [45] achieved by applying the principle
of least commitment, through which the interface of an object provides its essential behavior, and
nothing more [46]. We like to use an additional principle that we call the principle of least
astonishment, through which an abstraction captures the entire behavior of some object, no more
and no less, and offers no surprises or side effects that go beyond the scope of the abstraction.
Deciding on the right set of abstractions for a given domain is the central problem in object-
oriented design. Because this topic is so important, the whole of Chapter 4 is devoted to it.
“There is a spectrum of abstraction, from objects which closely model problem domain entities
to objects which really have no reason for existence” [47]. From the most to the least useful,
these kinds of abstractions include the following:
■ Entity abstraction An object that represents a useful model of a problem domain or solution
domain entity
■ Action abstraction An object that provides a generalized set of operations, all of which perform
the same kind of function
■ Virtual machine abstraction An object that groups operations that are all used by some superior
level of control, or operations that all use some junior-level set of operations

31
■ Coincidental abstraction An object that packages a set of operations that have no relation to
each otherWe strive to build entity abstractions because they directly parallel the vocabulary of a
given problem domain.
A client is any object that uses the resources of another object (known as the server). We can
characterize the behavior of an object by considering the services that it provides to other
objects, as well as the operations that it may perform on other objects. This view forces us to
concentrate on the outside view of an object and leads us to what Meyer calls the contract model
of programming [48]: the outside view of each obje ct defines a contract on which other objects
may depend, and which in turn must be carried out by the inside view of the object itself (often
in collaboration with other objects). This contract thus establishes all the assumptions a client
object may make about the behavior of a server object. In other words, this contract encompasses
the responsibilities of an object, namely, the behavior for which it is held accountable [49].
Individually, each operation that contributes to this contract has a unique signature comprising
all of its formal arguments and return type. We call the entire set of operations that a client may
perform on an object, together with the legal orderings in which they may be invoked, its
protocol. A protocol denotes the ways in which an object may act and react and thus constitutes
the entire static and dynamic outside view of the abstraction.
Central to the idea of an abstraction is the concept of invariance. An invariant is some Boolean
(true or false) condition whose truth must be preserved. For each operation associated with an
object, we may define preconditions (invariants assumed by the operation) as well as
postconditions (invariants satisfied by the operation). Violating an invariant breaks the contract
associated with an abstraction. If a precondition is violated, this means that a client has not
satisfied its part of the bargain, and hence the server cannot proceed reliably. Similarly, if a
postcondition is violated, this means that a server has not carried out its part of the contract, and
so its clients can no longer trust the behavior of the server. An exception is an indication that
some invariant has not been or cannot be satisfied.
Certain languages permit objects to throw exceptions so as to abandon processing and alert some
other object to the problem, which in turn may catch the exception and handle the problem.
As an aside, the terms operation, method, and member function evolved from three different
programming cultures (Ada, Smalltalk, and C++, respectively). They all mean virtually the same
thing, so we will use them interchangeably. All abstractions have static as well as dynamic
properties. For example, a file object takes up a certain amount of space on a particular memory
device; it has a name, and it has contents. These are all static properties. The value of each of
these properties is dynamic, relative to the lifetime of the object: A file object procedure-oriented
style of programming, the activity that changes the dynamic value of objects is the central part of
all programs; things happen when subprograms are called and statements are executed. In a rule-
oriented style of programming, things happen when new events cause rules to fire, which in turn
may trigger other rules, and so on. In an object-oriented style of programming, things happen
whenever we operate on an object (i.e., when we send a message to an object). Thus, invoking an
operation on an object elicits some reaction from the object. What operations we can
meaningfully perform on an object and how that object reacts constitute the entire behavior of
the object.

32
Examples of Abstraction
Let’s illustrate these concepts with some
examples. We defer a complete treatment of
how to find the right abstractions for a given
problem to Chapter 4. On a hydroponics
farm, plants are grown in a nutrient solution,
without sand, gravel, or other soils.
Maintaining the proper greenhouse
environment is a delicate job and depends on
the kind of plant being grown and its age.
One must control diverse factors such as
temperature, humidity, light, pH, and nutrient
concentrations. On a large farm, it is not
unusual to have an automated system that
constantly monitors and adjusts these
elements. Simply stated, the purpose of an
automated gardener is to efficiently carry
out, with minimal human intervention, growing plans for the healthy production of multiple
crops.
One of the key abstractions in this problem is that of a sensor. Actually, there are several
different kinds of sensors. Anything that
affects production must be measured, so we
must have sensors for air and water
temperature, humidity, light, pH, and nutrient
concentrations, among other things. Viewed
from the outside, a temperature sensor is
simply an object that knows how to measure
the temperature at some specific location.
What is a temperature? It is some numeric
value, within a limited range of values and
with a certain precision, that represents
degrees in the scale of Fahrenheit, Centigrade,
or Kelvin, whichever is most appropriate for
our problem. What is a location? It is some
identifiable place on the farm at which we
desire to measure the temperature;
presumably, there are only a few such locations. What is important for a temperature sensor is
not so much where it is located but the fact that it has a location and identity unique from all
other temperature sensors. Now we are ready to ask: What are the responsibilities of a
temperature sensor? Our design decision is that a sensor is responsible for knowing the
temperature at a given location and reporting that temperature when asked. More concretely,
what operations can a client perform on a temperature sensor? Our design decision is that a client
can calibrate it, as well as ask what the current temperature is. (See Figure 2–6. Note that this
representation is similar to the representation of a class in UML 2.0).

33
The abstraction we have described thus far is passive; some client object must operate on an air
Temperature Sensor object to determine its current temperature. However, there is another
legitimate abstraction that may be more
or less appropriate depending on the
broader system design decisions we
might make. Specifically, rather than the
Temperature Sensor being passive, we
might make it active, so that it is not
acted on but rather acts on other objects
whenever the temperature at its location
changes a certain number of degrees from
a given set point. This abstraction is
almost the same as our first one, except
that its responsibilities have changed
slightly: A sensor is now responsible for
reporting the current temperature when it changes, not just when asked. What new operations
must this abstraction provide? This abstraction is a bit more complicated than the first (see
Figure 2–7). A client of this abstraction may invoke an operation to establish a critical range of
temperatures. It is then the responsibility of the sensor to report whenever the temperature at its
location drops below or rises above the given setpoint. When the function is invoked, the sensor
provides its location and the current temperature, so that the client has sufficient information to
respond to the condition.
How the Active Temperature Sensor carries out its responsibilities is a function of its inside view
and is of no concern to outside clients. These then are the secrets of the class, which are
implemented by the class’s private parts together with the definition of its member functions.
Let’s consider a different abstraction. For each crop, there must be a growing plan that describes
how temperature, light, nutrients, and other conditions should change over time to maximize the
harvest. A growing plan is a legitimate entity abstraction because it forms part of the vocabulary
of the problem domain. Each crop has its own growing plan, but the growing plans for all crops
take the same form.
A growing plan is responsible for
keeping track of all interesting actions
associated with growing a crop,
correlated with the times at which those
actions should take place. For example,
on day 15 in the lifetime of a certain
crop, our growing plan might be to
maintain a temperature of 78°F for 16
hours, turn on the lights for 14 of these
hours, and then drop the temperature to
65°F for the rest of the day. We might
also want to add certain extra nutrients
in the middle of the day, while still maintaining a slightly acidic pH. From the perspective
outside of each growing-plan object, a client must be able to establish the details of a plan,
modify a plan, and inquire about a plan, as shown in Figure 2–8. (Note that abstractions are

34
likely to evolve over the lifetime of a project. As details begin to be fleshed out, a responsibility
such as “establish plan” could turn into multiple responsibilities, such as “set temperature,” “set
pH,” and so forth. This is to be expected as more knowledge of client requirements is gained,
designs mature, and implementation approaches are considered.)
Our decision is also that we will not
require a growing plan to carry out its
plan: We will leave this as the
responsibility of a different abstraction
(e.g., a Plan Controller). In this manner,
we create a clear separation of concerns
among the logically different parts of the
system, so as to reduce the conceptual
size of each individual abstraction. For
example, there might be an object that
sits at the boundary of the
human/machine interface and translates
human input into plans. This is the object
that establishes the details of a growing
plan, so it must be able to change the
state of a Growing Plan object. There
must also be an object that carries out the growing plan, and it must be able to read the details of
a plan for a particular time. As this example points out, no object stands alone; every object
collaborates with other objects to achieve some behavior. Our design decisions about how these
objects cooperate with one another define the boundaries of each abstraction and thus the
responsibilities and protocol of each object.
The Meaning of Encapsulation
Although we earlier described our abstraction of
the Growing Plan as a time action mapping, its
implementation is not necessarily a literal table
or map data structure. Indeed, whichever
representation is chosen is immaterial to the
client’s contract with the Growing Plan, as long
as that representation upholds the contract.
Simply stated, the abstraction of an object should
precede the decisions about its implementation.
Once an implementation is selected, it should be
treated as a secret of the abstraction and hidden
from most clients. Abstraction and encapsulation
are complementary concepts: Abstraction focuses on the observable behavior of an object,
whereas encapsulation focuses on the implementation that gives rise to this behavior.
Encapsulation is most often achieved through information hiding (not just data hiding), which is
the process of hiding all the secrets of an object that do not contribute to its essential
characteristics; typically, the structure of an object is hidden, as well as the implementation of its
methods. “No part of a complex system should depend on the internal details of any other part”

35
[50]. Whereas abstraction “helps people to think about what they are doing,” encapsulation
“allows program changes to be reliably made with limited effort” [51].
Encapsulation provides explicit barriers among different abstractions and thus leads to a clear
separation of concerns. For example, consider again the structure of a plant. To understand how
photosynthesis works at a high level of abstraction, we can ignore details such as the
responsibilities of plant roots or the chemistry of cell walls. Similarly, in designing a database
application, it is standard practice to write programs so that they don’t care about the physical
representation of data but depend only on a schema that denotes the data’s logical view [52]. In
both of these cases, objects at one level of abstraction are shielded from implementation details
at lower levels of abstraction.
“For abstraction to work, implementations must be encapsulated” [53]. In practice, this means
that each class must have two parts: an interface and an implementation. The interface of a class
captures only its outside view, encompassing our abstraction of the behavior common to all
instances of the class. The implementation of a class comprises the representation of the
abstraction as well as the mechanisms that achieve the desired behavior. The interface of a class
is the one place where we assert all of the assumptions that a client may make about any
instances of the class; the implementation encapsulates details about which no client may make
assumptions.
To summarize, we define encapsulation as follows: Encapsulation is the process of
compartmentalizing the elements of an abstraction that constitute its structure and behavior;
encapsulation serves to separate the contractual interface of an abstraction and its
implementation. Britton and Parnas call these encapsulated elements the “secrets” of an
abstraction [54].
Examples of Encapsulation
To illustrate the principle of encapsulation, let’s return to the problem of the Hydroponics
Gardening System. Another key
abstraction in this problem domain
is that of a heater. A heater is at a
fairly low level of abstraction, and
thus we might decide that there are
only three meaningful operations
that we can perform on this object:
turn it on, turn it off, and find out if
it is running. All a client needs to
know about the class Heater is its
available interface (i.e., the
responsibilities that it may execute
at the client’s request—see Figure 2–9). Turning to the inside view of the Heater, we have an
entirely different perspective. Suppose that our system engineers have decided to locate the
computers that control each greenhouse away from the building (perhaps to avoid the harsh
environment) and to connect each computer to its sensors and actuators via serial lines. One
reasonable implementation for the Heater class might be to use an electromechanical relay that

36
controls the power going to each physical heater, with the relays in turn commanded by
messages sent along these serial lines. For example, to turn on a heater, we might transmit a
special command string, followed by a number identifying the specific heater, and followed by
another number used to signal turning the heater on.
Suppose that for whatever reason our system engineers choose to use memory mapped I/O
instead of serial communication lines. We would not need to change the interface of the Heater,
yet the implementation would be very different. The client would not see any change at all as the
client sees only the Heater interface. This is the key point of encapsulation. In fact, the client
should not care what the implementation is, as long as it receives the service it needs from the
Heater. Let’s next consider the implementation of the class GrowingPlan. As we mentioned
earlier, a growing plan is essentially a time/action mapping. Perhaps the most reasonable
representation for this abstraction would be a dictionary of time/ action pairs, using an open hash
table. We need not store an action for every hour, because things don’t change that quickly.
Rather, we can store actions only for when they change, and have the implementation extrapolate
between times. In this manner, our implementation encapsulates two secrets: the use of an open
hash table (which is distinctly a part of the vocabulary of the solution domain, not the problem
domain) and the use of extrapolation to reduce our storage requirements (otherwise we would
have to store many more time/action pairs over the duration of a growing season). No client of
this abstraction need ever know about these implementation decisions because they do not
materially affect the outwardly observable behavior of the class. Intelligent encapsulation
localizes design decisions that are likely to change. As a system evolves, its developers might
discover that, in actual use, certain operations take longer than is acceptable or that some objects
consume more space than is available. In such situations, the representation of an object is often
changed so that more efficient algorithms can be applied or so that one can optimize for space by
calculating rather than storing certain data. This ability to change the representation of an
abstraction without disturbing any of its clients is the essential benefit of encapsulation.

37
Hiding is a relative concept: What is hidden at one level of abstraction may represent the outside
view at another level of abstraction. The underlying representation of an object can be revealed,
but in most cases only if the creator of the abstraction explicitly exposes the implementation, and
then only if the client is willing to accept the resulting additional complexity. Thus,
encapsulation cannot stop a developer from doing stupid things; as Stroustrup points out,
“Hiding is for the prevention of accidents, not the prevention of fraud” [56]. Of course, no
programming language prevents a human from literally seeing the implementation of a class,
although an operating system might deny access to a particular file that contains the
implementation of a class.
The Meaning of Modularity
“The act of partitioning a program into individual components can reduce its complexity to some
degree. . . . Although partitioning a program
is helpful for this reason, a more powerful
justification for partitioning a program is that
it creates a number of well-defined,
documented boundaries within the program.
These boundaries, or interfaces, are
invaluable in the comprehension of the
program” [57]. In some languages, such as
Smalltalk, there is no concept of a module, so
the class forms the only physical unit of
decomposition. Java has packages that
contain classes. In many other languages,
including Object Pascal, C++, and Ada, the
module is a separate language construct and
therefore warrants a separate set of design
decisions. In these languages, classes and objects form the logical structure of a system; we
place these abstractions in modules to produce the system’s physical architecture. Especially for
larger applications, in which we may have many hundreds of classes, the use of modules is
essential to help manage complexity.
“Modularization consists of dividing a program into modules which can be compiled separately,
but which have connections with other modules. We will use the definition of Parnas: ‘The
connections between modules are the assumptions which the modules make about each other’”
[58]. Most languages that support the module as a separate concept also distinguish between the
interface of a module and its implementation. Thus, it is fair to say that modularity and
encapsulation go hand in hand.
Deciding on the right set of modules for a given problem is almost as hard a problem as deciding
on the right set of abstractions. Zelkowitz is absolutely right when he states that “because the
solution may not be known when the design stage starts, decomposition into smaller modules
may be quite difficult. For older applications (such as compiler writing), this process may
become standard, but for new ones (such as defense systems or spacecraft control), it may be
quite difficult” [59].

38
Modules serve as the physical containers in which we declare the classes and objects of our
logical design. This is no different than the situation faced by the electrical engineer designing a
computer motherboard. NAND, NOR, and NOT gates might be used to construct the necessary
logic, but these gates must be physically packaged in standard integrated circuits. Lacking any
such standard software parts, the software engineer has considerably more degrees of freedom—
as if the electrical engineer had a silicon foundry at his or her disposal.
For tiny problems, the developer might decide to declare every class and object in the same
package. For anything but the most trivial software, a better solution is to group logically related
classes and objects in the same module and to expose only those elements that other modules
absolutely must see. This kind of modularization is a good thing, but it can be taken to extremes.
For example, consider an application that runs on a distributed set of processors and uses a
message passing mechanism to coordinate the activities of different programs. In a large system,
such as a command and control system, it is common to have several hundred or even a few
thousand kinds of messages. A naive strategy might be to define each message class in its own
module. As it turns out, this is a singularly poor design decision. Not only does it create a
documentation nightmare, but it makes it terribly difficult for any users to find the classes they
need. Furthermore, when decisions change, hundreds of modules must be modified or
recompiled. This example shows how information hiding can backfire [60]. Arbitrary
modularization is sometimes worse than no modularization at all.
In traditional structured design, modularization is primarily concerned with the meaningful
grouping of subprograms, using the criteria of coupling and cohesion. In object-oriented design,
the problem is subtly different: The task is to decide where to physically package the classes and
objects, which are distinctly different from subprograms.
Our experience indicates that there are several useful technical as well as nontechnical guidelines
that can help us achieve an intelligent modularization of classes and objects. As Britton and
Parnas have observed, “The overall goal of the decomposition into modules is the reduction of
software cost by allowing modules to be designed and revised independently. . . . Each module’s
structure should be simple enough that it can be understood fully; it should be possible to change
the implementation of other modules without knowledge of the implementation of other modules
and without affecting the behavior of other modules; [and] the ease of making a change in the
design should bear a reasonable relationship to the likelihood of the change being needed” [61].
There is a pragmatic edge to these guidelines. In practice, the cost of recompiling the body of a
module is relatively small: Only that unit need be recompiled and the application relinked.
However, the cost of recompiling the interface of a module is relatively high. Especially with
strongly typed languages, one must recompile the module interface, its body, all other modules
that depend on this interface, the modules that depend on these modules, and so on. Thus, for
very large programs (assuming that our development environment does not support incremental
compilation), a change in a single module interface might result in much longer compilation
time. Obviously, a development manager cannot often afford to allow a massive “big bang”
recompilation to happen too frequently. For this reason, a module’s interface should be as narrow
as possible, yet still satisfy the needs of the other modules that use it. Our style is to hide as much
as we can in the implementation of a module. Incrementally shifting declarations from a
module’s implementation to its interface is far less painful and destabilizing than ripping out
extraneous interface code.

39
The developer must therefore balance two competing technical concerns: the desire to
encapsulate abstractions and the need to make certain abstractions visible to other modules.
“System details that are likely to change independently should be the secrets of separate
modules; the only assumptions that should appear between modules are those that are considered
unlikely to change. Every data structure is private to one module; it may be directly accessed by
one or more programs within the module but not by programs outside the module. Any other
program that requires information stored in a module’s data structures must obtain it by calling
module programs” [62]. In other words, strive to build modules that are cohesive (by grouping
logically related abstractions) and loosely coupled (by minimizing the dependencies among
modules). From this perspective, we may define modularity as follows: Modularity is the
property of a system that has been decomposed into a set of cohesive and loosely coupled
modules. Thus, the principles of abstraction, encapsulation, and modularity are synergistic. An
object provides a crisp boundary around a single abstraction, and both encapsulation and
modularity provide barriers around this abstraction. Two additional technical issues can affect
modularization decisions. First, since modules usually serve as the elementary and indivisible
units of software that can be reused across applications, a developer might choose to package
classes and objects into modules in a way that makes their reuse convenient. Second, many
compilers generate object code in segments, one for each module. Therefore, there may be
practical limits on the size of individual modules. With regard to the dynamics of subprogram
calls, the placement of declarations within modules can greatly affect the locality of reference
and thus the paging behavior of a virtual memory system. Poor locality happens when
subprogram calls occur across segments and lead to cache misses and page thrashing that
ultimately slow down the whole system.
Several competing nontechnical needs may also affect modularization decisions. Typically, work
assignments in a development team are given on a module-bymodule basis, so the boundaries of
modules may be established to minimize the interfaces among different parts of the development
organization. Senior designers are usually given responsibility for module interfaces, and more
junior developers complete their implementation. On a larger scale, the same situation applies
with subcontractor relationships. Abstractions may be packaged so as to quickly stabilize the
module interfaces as agreed upon among the various companies. Changing such interfaces
usually involves much wailing and gnashing of teeth— not to mention a vast amount of
paperwork—so this factor often leads to conservatively designed interfaces. Speaking of
paperwork, modules also usually serve as the unit of documentation and configuration
management. Having ten modules where one would do sometimes means ten times the
paperwork, and so, unfortunately, sometimes the documentation requirements drive the module
design decisions (usually in the most negative way). Security may also be an issue. Most code
may be considered unclassified, but other code that might be classified secret or higher is best
placed in separate modules. Juggling these different requirements is difficult, but don’t lose sight
of the most important point: Finding the right classes and objects and then organizing them into
separate modules are largely independent design decisions. The identification of classes and
objects is part of the logical design of the system, but the identification of modules is part of the
system’s physical design. One cannot make all the logical design decisions before making all the
physical ones, or vice versa; rather, these design decisions happen iteratively.

40
Examples of Modularity
Let’s look at modularity in the Hydroponics Gardening System. Suppose we decide to use a
commercially available workstation where the user can control the system’s operation. At this
workstation, an operator could create new growing plans, modify old ones, and follow the
progress of currently active ones. Since one of our key abstractions here is that of a growing
plan, we might therefore create a module whose purpose is to collect all of the classes associated
with individual growing plans (e.g., FruitGrowingPlan, GrainGrowingPlan). The
implementations of these GrowingPlan classes would appear in the implementation of this
module. We might also define a module whose purpose is to collect all of the code associated
with all user interface functions. Our design will probably include many other modules.
Ultimately, we must define some main program from which we can invoke this application. In
object oriented design, defining this main program is often the least important decision, whereas
in traditional structured design, the main program serves as the root, the keystone that holds
everything else together. We suggest that the object-oriented view is more natural, for, as Meyer
observes, “Practical software systems are more appropriately described as offering a number of
services. Defining these systems by single functions is usually possible, but yields rather
artificial answers. . . . Real systems have no top” [63].
The Meaning of Hierarchy
Abstraction is a good thing, but in all except the most trivial applications, we may find many
more different abstractions than we can comprehend at one time. Encapsulation helps manage
this complexity by hiding the inside view of our abstractions. Modularity helps also, by giving us
a way to cluster logically related abstractions. Still, this is not enough. A set of abstractions often
forms a hierarchy, and by identifying these hierarchies in our design, we greatly simplify our
understanding of the problem.
We define hierarchy as follows:
Hierarchy is a ranking or ordering of abstractions. The two most important hierarchies in a
complex system are its class structure (the “is a” hierarchy) and its object structure (the “part of”
hierarchy).
Examples of Hierarchy: Single Inheritance
Inheritance is the most important “is a” hierarchy, and as
we noted earlier, it is an essential element of object-
oriented systems. Basically, inheritance defines a
relationship among classes, wherein one class shares the
structure or behavior defined in one or more classes
(denoting single inheritance and multiple inheritances,
respectively). Inheritance thus represents a hierarchy of
abstractions, in which a subclass inherits from one or more
superclasses. Typically, a subclass augments or redefines
the existing structure and behavior of its superclasses.

41
Semantically, inheritance denotes an “is a” relationship. For example, a bear “is a” kind of
mammal, a house “is a” kind of tangible asset, and a quick sort “is a” particular kind of sorting
algorithm. Inheritance thus implies a generalization/ specialization hierarchy, wherein a subclass
specializes the more general structure or behavior of its superclasses. Indeed, this is the litmus
test for inheritance: If Bis not a kind of A, then B should not inherit from A. Consider the
different kinds of growing plans we might use in the Hydroponics Gardening System. An earlier
section described our abstraction of a very generalized growing plan. Different kinds of crops,
however, demand specialized growing plans. For example, the growing plan for all fruits is
generally the same but is quite different from the plan for all vegetables, or for all floral crops.
Because of this clustering of abstractions, it is reasonable to define a standard fruitgrowing plan
that encapsulates the behavior common to all fruits, such as the knowledge of when to pollinate
or when to harvest the fruit. We can assert that FruitGrowingPlan “is a” kind of GrowingPlan.
In this case, FruitGrowingPlan is more specialized, and GrowingPlan is more general. The same
could be said for GrainGrowingPlan or VegetableGrowingPlan, that is, GrainGrowingPlan “is a”
kind of GrowingPlan, and VegetableGrowingPlan “is a” kind of GrowingPlan. Here,
GrowingPlan is the more general superclass, and the others are specialized subclasses.
As we evolve our inheritance hierarchy, the structure and behavior that are common for different
classes will tend to migrate to common superclasses. This is why we often speak of inheritance
as being a generalization/specialization hierarchy. Superclasses represent generalized
abstractions, and subclasses represent specializations in which fields and methods from the
superclass are added, odified, or even hidden. In this manner, inheritance lets us state our
abstractions with an economy of expression. Indeed, neglecting the “is a” hierarchies that exist
can lead to bloated, inelegant designs. “Without inheritance, every class would be a free-standing
unit, each developed from the ground up. Different classes would bear no relationship with one
another, since the developer of each provides methods in whatever manner he chooses. Any
consistency across classes is the result of discipline on the part of the programmers. Inheritance
makes it possible to define new software in the same way we introduce any concept to a
newcomer, by comparing it with something that is already familiar” [64].
There is a healthy tension among the principles of abstraction, encapsulation, and hierarchy.
“Data abstraction attempts to provide an opaque barrier behind which methods and state are
hidden; inheritance requires opening this interface to some extent and may allow state as well as
methods to be accessed without abstraction” [65]. For a given class, there are usually two kinds
of clients: objects that invoke operations on instances of the class and subclasses that inherit
from the class. Liskov therefore notes that, with inheritance, encapsulation can be violated in one
of three ways: “The subclass might access an instance variable of its superclass, call a private
operation of its superclass, or refer directly to superclasses of its superclass” [66]. Different
programming languages trade off support for encapsulation and inheritance in different ways.
C++ and Java offer great flexibility. Specifically, the interface of a class may have three parts:
private parts, which declare members that are accessible only to the class itself; protected parts,
which declare members that are accessible only to the class and its subclasses; and public parts,
which are accessible to all clients.

42
Examples of Hierarchy: Multiple Inheritance
The previous example illustrated the use of single inheritance: the subclass FruitGrowingPlan
had exactly one superclass, the class GrowingPlan. For certain abstractions, it is useful to
provide inheritance from multiple superclasses. For example, suppose that we choose to define a
class representing a kind of plant. Our analysis of the problem domain might suggest that
flowering plants and fruits and vegetables have specialized properties that are relevant to our
application.
For example, given a flowering plant, its expected time to flower and time to seed might be
important to us. Similarly, the time to harvest might be an important part of our abstraction of all
fruits and vegetables. One way we could capture our design decisions would be to make two new
classes, a Flower class and a FruitVegetable class, both subclasses of the class Plant. However,
what if we need to model a plant that both flowered and produced fruit? For example, florists
commonly use blossoms from apple, cherry, and plum trees. For this abstraction, we would need
to invent a third class, lowerFruitVegetable, that duplicated information from the Flower and
FruitVegetable classes.
A better way to express our abstractions and thereby avoid this redundancy is to use multiple
inheritance. First, we invent classes that
independently capture the properties
unique to flowering plants and to fruits
and vegetables. These two classes have
no superclass; they stand alone. These
are called mixin classes because they
are meant to be mixed together with
other classes to produce new subclasses.
For example, we can define a Rose class
(see Figure 2–10) that inherits from
both Plant and FlowerMixin. Instances
of the subclass Rose thus include the
structure and behavior from the class Plant together with the structure and behavior from the
class FlowerMixin. Similarly, a Carrot class could be as shown in Figure 2–11. In both cases, we
form the subclass by inheriting from two superclasses. Now, suppose we want to declare a class
for a plant such as the cherry tree that has both flowers and fruit. This would be conceptualized
as shown in Figure 2–12.

43
Multiple inheritance is conceptually straightforward, but it does introduce some practical
complexities for programming languages. Languages must address two issues: clashes among
names from different superclasses and repeated inheritance. Clashes will occur when two or
more superclasses provide a field or operation with the same name or signature as a peer
superclass. Repeated inheritance occurs when two or more peer superclasses share a common
superclass. In such a situation, the
inheritance lattice will be diamond-
shaped, so the question arises, does
the leaf class (i.e., subclass) have one
copy or multiple copies of the
structure of the shared superclass?
(See Figure 2–13.) Some languages
prohibit repeated inheritance, some
unilaterally choose one approach,
and others, such as C++, permit the
programmer to decide. In C++,
virtual base classes are used to
denote a sharing of repeated
structures, whereas nonvirtual base
classes result in duplicate copies
appearing in the subclass (with
explicit qualification required to
distinguish among the copies).
Multiple inheritance is often overused. For example, cotton candy is a kind of candy, but it is
distinctly not a kind of cotton. Again, the litmus test for inheritance applies: If B is not a kind of
A, then B should not inherit from A. Ill-formed multiple inheritance lattices should be reduced to
a single superclass plus aggregation of the other classes by the subclass, where possible.

44
Examples of Hierarchy: Aggregation
Whereas these “is a” hierarchies denote generalization/specialization relationships,“part of”
hierarchies describe aggregation relationships. For example, consider the abstraction of a garden.
We can contend that a garden consists of a collection of plants together with a growing plan. In
other words, plants are “part of” the garden, and the growing plan is “part of” the garden. This
“part of” relationship is known as aggregation.
Aggregation is not a concept unique to object-oriented development or objectoriented
programming languages. Indeed, any language that supports record-like structures supports
aggregation. However, the combination of inheritance with aggregation is powerful: Aggregation
permits the physical grouping of logically related structures, and inheritance allows these
common groups to be easily reused among different abstractions.
When dealing with hierarchies such as these, we often speak of levels of abstraction, a concept
first described by Dijkstra [67]. In terms of its “is a” hierarchy, a high-level abstraction is
generalized, and a low-level abstraction is specialized. Therefore, we say that a Flower class is at
a higher level of abstraction than a Plant class. In terms of its “part of” hierarchy, a class is at a
higher level of abstraction than any of the classes that make up its implementation. Thus, the
class Garden is at a higher level of abstraction than the type Plant, on which it builds.
Aggregation raises the issue of ownership. Our abstraction of a garden permits different plants to
be raised in a garden over time, but replacing a plant does not change the identity of the garden
as a whole, nor does removing a garden necessarily destroy all of its plants (they are likely just
transplanted). In other words, the lifetime of a garden and its plants are independent. In contrast,
we have decided that a GrowingPlan object is intrinsically associated with a Garden object and
does not exist independently. Therefore, when we create an instance of Garden, we also create an
instance of GrowingPlan; when we destroy the Garden object, we in turn destroy the
GrowingPlan instance.
The Meaning of Typing
The concept of a type derives primarily from the
theories of abstract data types. As Deutsch
suggests, “A type is a precise characterization of
structural or behavioral properties which a
collection of entities all share” [68]. For our
purposes, we will use the terms type and class
interchangeably. Although the concepts of a type
and a class are similar, we include typing as a
separate element of the object model because the
concept of a type places a very different emphasis
on the meaning of abstraction. Specifically, we
state the following: Typing is the enforcement of
the class of an object, such that objects of
different types may not be interchanged, or at the
most, they may be interchanged only in very

45
restricted ways. Typing lets us express our abstractions so that the programming language in
which we implement them can be made to enforce design decisions. A given programming
language may be strongly typed, weakly typed, or even untyped, yet still be called object-
oriented. For example, Eiffel is strongly typed, meaning that type conformance is strictly
enforced: Operations cannot be called on an object unless the exact signature of that operation is
defined in the object’s class or superclasses. The idea of conformance is central to the notion of
typing. For example, consider units of measurement in physics [71]. When we divide distance by
time, we expect some value denoting speed, not weight. Similarly, dividing a unit of force by
temperature doesn’t make sense, but dividing force by mass does. These are both examples of
strong typing, wherein the rules of our domain prescribe and enforce certain legal combinations
of abstractions.
Strong typing lets us use our programming language to enforce certain design decisions and so is
particularly relevant as the complexity of our system grows. However, there is a dark side to
strong typing. Practically, strong typing introduces semantic dependencies such that even small
changes in the interface of a base class require recompilation of all subclasses. There are two
general solutions to these problems. First, we could use a type-safe container class that
manipulates only objects of a specific class. This approach addresses the first problem, wherein
objects of different types are incorrectly mingled. Second, we could use some form of runtime
type identification; this addresses the second problem of knowing what kind of object you
happen to be examining at the moment. In general, however, runtime type identification should
be used only when there is a compelling reason because it can represent a weakening of
encapsulation. As we will discuss in the next section, the use of polymorphic operations can
often (but not always) mitigate the need for runtime type identification.
As Tesler points out, there are a number of important benefits to be derived from using strongly
typed languages:
■ Without type checking, a program in most languages can ‘crash’ in mysterious ways at
runtime.
■ In most systems, the edit-compile-debug cycle is so tedious that early error detection is
indispensable.
■ Type declarations help to document programs.
■ Most compilers can generate more efficient object code if types are declared. [72]
Untyped languages offer greater flexibility, but even with untyped languages, as Borning and
Ingalls observe, “In almost all cases, the programmer in fact knows what sorts of objects are
expected as the arguments of a message, and what sort of object will be returned” [73]. In
practice, the safety offered by strongly typed languages usually more than compensates for the
flexibility lost by not using an untyped language, especially for programming-in-the-large.
Examples of Typing: Static and Dynamic Typing
The concepts of strong and weak typing and static and dynamic typing are entirely different.
Strong and weak typing refers to type consistency, whereas static and dynamic typing refers to

46
the time when names are bound to types. Static typing (also known as static binding or early
binding) means that the types of all variables and expressions are fixed at the time of
compilation; dynamic typing (also known as late binding) means that the types of all variables
and expressions are not known until runtime. A language may be both strongly and statically
typed (Ada), strongly typed yet supportive of dynamic typing (C++, Java), or untyped yet
supportive of dynamic typing (Smalltalk).
Polymorphism is a condition that exists when the features of dynamic typing and inheritance
interact. Polymorphism represents a concept in type theory in which a single name (such as a
variable declaration) may denote objects of many different classes that are related by some
common superclass. Any object denoted by this name is therefore able to respond to some
common set of operations [74]. The opposite of polymorphism is monomorphism, which is found
in all languages that are both strongly and statically typed. Polymorphism is perhaps the most
powerful feature of object-oriented programming languages next to their support for abstraction,
and it is what distinguishes object-oriented programming from more traditional programming
with abstract data types. As we will see in the following chapters, polymorphism is also a central
concept in object-oriented design.
The Meaning of Concurrency
For certain kinds of problems, an automated system may have to handle many different events
simultaneously. Other problems may involve so much computation that they exceed the capacity
of any single processor. In each of these
cases, it is natural to consider using a
distributed set of computers for the
target implementation or to use
multitasking. A single process is the
root from which independent dynamic
action occurs within a system. Every
program has at least one thread of
control, but a system involving
concurrency may have many such
threads: some that are transitory and
others that last the entire lifetime of the
system’s execution.
Systems executing across multiple CPUs allow for truly concurrent threads of control, whereas
systems running on a single CPU can only achieve the illusion of concurrent threads of control,
usually by means of some time-slicing algorithm. We also distinguish between heavyweight and
lightweight concurrency. A heavyweight process is one that is typically independently managed
by the target operating system and so encompasses its own address space. A lightweight process
usually lives within a single operating system process along with other lightweight processes,
which share the same address space. Communication among heavyweight processes is generally
expensive, involving some form of interprocess communication; communication among
lightweight processes is less expensive and often involves shared data. Building a large piece of
software is hard enough; designing one that encompasses multiple threads of control is much
harder because one must worry about such issues as deadlock, livelock, starvation, mutual

47
exclusion, and race conditions. “At the highest levels of abstraction, OOP can alleviate the
concurrency problem for the majority of programmers by hiding the concurrency inside reusable
abstractions” [76]. Black et al. therefore suggest that “an object model is appropriate for a
distributed system because it implicitly defines (1) the units of distribution and movement and
(2) the entities that communicate” [77]. Whereas object-oriented programming focuses on data
abstraction, encapsulation, and inheritance, concurrency focuses on process abstraction and
synchronization [78]. The object is a concept that unifies these two different viewpoints: Each
object (drawn from an abstraction of the real world) may represent a separate thread of control (a
process abstraction). Such objects are called active. In a system based on an object-oriented
design, we can conceptualize the world as consisting of a set of cooperative objects, some of
which are active and thus serve as centers of independent activity. Given this conception, we
define concurrency as follows: Concurrency is the property that distinguishes an active object
from one that is not active.
Examples of Concurrency
Let’s consider a sensor named ActiveTemperatureSensor, whose behavior requires periodically
sensing the current temperature and then notifying the client whenever the temperature changes a
certain number of degrees from a given setpoint. We do not explain how the class implements
this behavior. That fact is a secret of the implementation, but it is clear that some form of
concurrency is required. In general, there are three approaches to concurrency in object-oriented
design. First, concurrency is an intrinsic feature of certain programming languages, which
provide mechanisms for concurrency and synchronization. In this case, we may create an active
object that runs some process concurrently with all other active objects.
Second, we may use a class library that implements some form of lightweight processes.
Naturally, the implementation of this kind is highly platform-dependent, although the interface to
the library may be relatively portable. In this approach, concurrency is not an intrinsic part of the
language (and so does not place any burdens on nonconcurrent systems) but appears as if it were
intrinsic, through the presence of these standard classes.
Third, we may use interrupts to give us the illusion of concurrency. Of course, this requires that
we have knowledge of certain low-level hardware details. For example, in our implementation of
the class ActiveTemperatureSensor, we might have a hardware timer that periodically interrupts
the application, during which time all such sensors read the current temperature and then invoke
their callback function as necessary.
No matter which approach to concurrency we take, one of the realities about concurrency is that
once you introduce it into a system, you must consider how active objects synchronize their
activities with one another as well as with objects that are purely sequential. For example, if two
active objects try to send messages to a third object, we must be certain to use some means of
mutual exclusion, so that the state of the object being acted on is not corrupted when both active
objects try to update its state simultaneously. This is the point where the ideas of abstraction,
encapsulation, and concurrency interact. In the presence of concurrency, it is not enough simply
to define the methods of an object; we must also make certain that the semantics of these
methods are preserved in the presence of multiple threads of control.

48
The Meaning of Persistence
An object in software takes up some amount of space and exists for a particular amount of time.
Atkinson et al. suggest that there is a continuum of object existence, ranging from transitory
objects that arise within the evaluation of an expression to objects in a database that outlive the
execution of a single program. This spectrum of object persistence encompasses the following:
■ Transient results in expression evaluation
■ Local variables in procedure activations
■ Own variables [as in ALGOL 60], global variables, and heap items whose extent is different
from their scope
■ Data that exists between executions of a program
■ Data that exists between various versions of a program
■ Data that outlives the program [79]
Traditional programming languages usually address only the first three kinds of object
persistence; persistence of the last three kinds is typically the domain of database technology.
This leads to a clash of cultures that sometimes results in very strange architectures:
Programmers end up crafting ad hoc schemes for storing objects whose state must be preserved
between program executions, and database designers misapply their technology to cope with
transient objects [80].
An interesting variant of Atkinson et al.’s “Data that
outlives the program” is the case of Web
applications where the application may not be
connected to the data it is using through the entire
transaction execution. What changes may happen to
data provided to a client application or Web service
while disconnected to the data source, and how
should resolution of the two be handled?
Frameworks like Microsoft’s ActiveX Data Object
for .NET (ADO.NET) have arisen to help address
such distributed, disconnected scenarios.
Unifying the concepts of concurrency and objects
gives rise to concurrent objectoriented programming languages. In a similar fashion, introducing
the concept of persistence to the object model gives rise to object-oriented databases. In practice,
such databases build on proven technology, such as sequential, indexed, hierarchical, network, or
relational database models, but then offer to the programmer the
abstraction of an object-oriented interface, through which database queries and other operations
are completed in terms of objects whose lifetimes transcend the lifetime of an individual
program. This unification vastly simplifies the development of certain kinds of applications. In

49
particular, it allows us to apply the same design methods to the database and nondatabase
segments of an application.
Some object-oriented programming languages provide direct support for persistence. Java
provides Enterprise Java Beans (EJBs) and Java Data Objects. Smalltalk has protocols for
streaming objects to and from storage (which must be redefined by subclasses). However,
streaming objects to flat files is a naive solution to persistence that does not scale well.
Persistence may be achieved through a modest number of commercially available object-oriented
databases [81]. A more typical approach to persistence is to provide an object-oriented skin over
a relational database. Customized object-relational mappings can be created by the individual
developer. However, that is a very challenging task to do well. Frameworks are available to ease
this task, such as the open source framework Hibernate [85]. Commercial object-relational
mapping software is available. This approach is most appealing when there is a large capital
investment in relational database technology that would be risky or too expensive to replace.
Persistence deals with more than just the lifetime of data. In object-oriented databases, not only
does the state of an object persist, but its class must also transcend any individual program, so
that every program interprets this saved state in the same way. This clearly makes it challenging
to maintain the integrity of a database as it grows, particularly if we must change the class of an
object.
Our discussion thus far pertains to persistence in time. In most systems, an object, once created,
consumes the same physical memory until it ceases to exist. However, for systems that execute
on a distributed set of processors, we must sometimes be concerned with persistence across
space. In such systems, it is useful to think of objects that can move from machine to machine
and that may even have different representations on different machines.
To summarize, we define persistence as follows:
Persistence is the property of an object through which its existence transcends time (i.e., the
object continues to exist after its creator ceases to exist) and/or space (i.e., the object’s location
moves from the address space in which it was created).
Applying the Object Model
As we have shown, the object model is fundamentally different from the models embraced by the
more traditional methods of structured analysis, structured design, and structured programming.
This does not mean that the object model abandons all of the sound principles and experiences of
these older methods.
Rather, it introduces several novel elements that build on these earlier models. Thus, the object
model offers a number of significant benefits that other models simply do not provide. Most
importantly, the use of the object model leads us to construct systems that embody the five
attributes of well-structured complex systems noted in Chapter 1: hierarchy, relative primitives
(i.e., multiple levels of abstraction), separation of concerns, patterns, and stable intermediate
forms. In our experience, there are five other practical benefits to be derived from the application
of the object model.

50
Benefits of the Object Model
First, the use of the object model helps us to exploit the expressive power of object-based and
object-oriented programming languages. As Stroustrup points out, “It is not always clear how
best to take advantage of a language such as C++. Significant improvements in productivity and
code quality have consistently been achieved using C++ as ‘a better C’ with a bit of data
abstraction thrown in where it is clearly useful. However, further and noticeably larger
improvements have been achieved by taking advantage of class hierarchies in the design process.
This is often called object-oriented design and this is where the greatest benefits of using C++
have been found” [82]. Our experience has been that, without the application of the elements of
the object model, the more powerful features of languages such as Smalltalk, C++, Java, and so
forth are either ignored or greatly misused.
Second, the use of the object model encourages the reuse not only of software but of entire
designs, leading to the creation of reusable application frameworks [83]. We have found that
object-oriented systems are often smaller than equivalent nonobject- oriented implementations.
Not only does this mean less code to write and maintain, but greater reuse of software also
translates into cost and schedule benefits. However, reuse does not just happen. If reuse is not a
primary goal of your project, it is unlikely that it will be achieved. Plus, designing for reuse may
cost you more when initially implementing the reusable component. The good news is that the
initial cost will be recovered in the subsequent uses of that component.
Third, the use of the object model produces systems that are built on stable intermediate forms,
which are more resilient to change. This also means that such systems can be allowed to evolve
over time, rather than be abandoned or completely redesigned in response to the first major
change in requirements. Chapter 7, Pragmatics, explains further how the object model reduces
the risks inherent in developing complex systems. This fourth benefit accrues primarily because
integration is spread out across the lifecycle rather than occurring as one major event. The object
model’s guidance in designing an intelligent separation of concerns also reduces development
risk and increases our confidence in the correctness of our design.
Finally, the object model appeals to the workings of human cognition. As Robson suggests,
“Many people who have no idea how a computer works find the idea of object-oriented systems
quite natural” [84].
Open Issues
To effectively apply the elements of the object model, we must next address several open issues.
■ What exactly are classes and objects?
■ How does one properly identify the classes and objects that are relevant to a particular
application?
■ What is a suitable notation for expressing the design of an object-oriented system?
■ What process can lead us to a well-structured object-oriented system?

51
■ What are the management implications of using object-oriented design?
These issues are the themes of the next five chapters.
Classes and Objects
The Nature of an Object
The ability to recognize physical objects is a skill that humans learn at a very early age. A
brightly colored ball will attract an infant’s attention, but typically, if you hide the ball, the child
will not try to look for it; when the object leaves her field of vision, as far as she can determine,
it ceases to exist. It is not until near the age of one that a child normally develops what is called
the object concept, a skill that is of critical importance to future cognitive development. Show a
ball to a one-year-old and then hide it, and she will usually search for it even though it is not
visible. Through the object concept, a child comes to realize that objects have a permanence and
identity apart from any operations on them [1].
What Is and What Isn’t an Object
In Chapter 1, we informally defined an object as a tangible entity that exhibits some well-defined
behavior. From the perspective of human cognition, an object is any of the following:
■ A tangible and/or visible thing
■ Something that may be comprehended intellectually
■ Something toward which thought or action is directed
We add to our informal definition the idea that an object models some part of reality and is
therefore something that exists in time and space. In software, the term object was first formally
applied in the Simula language; objects typically existed in Simula programs to simulate some
aspect of reality [2]. Real-world objects are not the only kinds of objects that are of interest to us
during software development. Other important kinds of objects are inventions of the design
process whose collaborations with other such objects serve as the mechanisms that provide some
higher-level behavior [3]. Jacobson et al. define control objects as “the ones that unite courses of
events and thus will carry on communication with other objects” [62]. This leads us to the more
refined definition of Smith and Tockey, who suggest that “an object represents an individual,
identifiable item, unit, or entity, either real or abstract, with a well-defined role in the problem
domain” [4].
Consider for a moment a manufacturing plant that processes composite materials for making
such diverse items as bicycle frames and airplane wings. Manufacturing plants are often divided
into separate shops: mechanical, chemical, electrical, and so forth. Shops are further divided into
cells, and in each cell we have some collection of machines, such as die stamps, presses, and
lathes. Along a manufacturing line, we might find vats containing raw materials, which are used
in a chemical process to produce blocks of composite materials, and which in turn are formed
and shaped to produce bicycle frames, airplane wings, and other end items. Each of the tangible
things we have mentioned thus far is an object. A lathe has a crisply defined boundary that

52
separates it from the block of composite material it operates on; a bicycle frame has a crisply
defined boundary that distinguishes it from the cell of machines that produced the frame itself.
Some objects may have crisp conceptual boundaries yet represent intangible events or processes.
For example, a chemical process in a manufacturing plant may be treated as an object because it
has a crisp conceptual boundary,
interacts with certain other objects
through a well-ordered collection
of operations that unfolds over
time, and exhibits a well-defined
behavior. Similarly, consider a
CAD/CAM system for modeling
solids. Where two solids such as a
sphere and a cube intersect, they
may form an irregular line of
intersection. Although it does not
exist apart from the sphere or cube,
this line is still an object with
crisply defined conceptual
boundaries.
Some objects may be tangible yet have fuzzy physical boundaries. Objects such as rivers, fog,
and crowds of people fit this definition.1 Just as the person holding a hammer tends to see
everything in the world as a nail, so the developer with an object-oriented mindset begins to
think that everything in the world is an object. This perspective is a little naive because some
things are distinctly not objects. For example, attributes such as beauty or color are not objects,
nor are emotions such as love and anger. On the other hand, these things are all potentially
properties of other objects. For example, we might say that a man (an object) loves his wife
(another object), or that a particular cat (yet another object) is gray. Thus, it is useful to say that
an object is something that has crisply defined boundaries, but this is not enough to guide us in
distinguishing one object from another, nor does it allow us to judge the quality of our
abstractions. Our experience therefore suggests the following definition. An object is an entity
that has state, behavior, and identity. The structure and behavior of similar objects are defined in
their common class. The terms instance and object are interchangeable. We will consider the
concepts of state, behavior, and identity in more detail in the sections that follow.
State
Consider a vending machine that dispenses soft drinks. The usual behavior of such objects is that
when someone puts money in a slot and pushes a button to make a selection, a drink emerges
from the machine. What happens if a user first makes a selection and then puts money in the
slot? Most vending machines just sit and do nothing because the user has violated the basic
assumptions of their operation. Stated another way, the vending machine was in a state (of
waiting for money) that the user ignored (by making a selection first). Similarly, suppose that the
user ignores the warning light that says, “Correct change only,” and puts in extra money. Most
machines are user-hostile; they will happily swallow the excess money.

53
In each of these circumstances, we see how the behavior of an object is influenced by its history:
The order in which one operates on the object is important. The reason for this event- and time-
dependent behavior is the existence of state within the object. For example, one essential state
associated with the vending machine is the amount of money currently entered by a user but not
yet applied to a selection. Other important properties include the amount of change available and
the quantity of soft drinks on hand. From this example, we may form the following low-level
definition. The state of an object encompasses all of the (usually static) properties of the object
plus the current (usually dynamic) values of each of these properties. Another property of a
vending machine is that it can accept money. This is a static (i.e., fixed) property, meaning that it
is an essential characteristic of a vending machine. In contrast, the actual quantity of money
accepted at any given moment represents the dynamic value of this property and is affected by
the order of operations on the machine. This quantity increases as a user inserts money and then
decreases when a product is vended. We say that values are “usually dynamic” because in some
cases values are static. For example, the serial number of a vending machine is a static property
and value. A property is an inherent or distinctive characteristic, trait, quality, or feature that
contributes to making an object uniquely that object.
For example, one essential property of an elevator is that it is constrained to travel up and down
and not horizontally. Properties are usually static because attributes such as these are unchanging
and fundamental to the nature of the object. We say “usually static” because in some
circumstances the properties of an object may change. For example, consider an autonomous
robot that can learn about its environment. It may first recognize an object that appears to be a
fixed barrier, only to learn later that this object is in fact a door that can be opened. In this case,
the object created by the robot as it builds its conceptual model of the world gains new properties
as new knowledge is acquired. All properties have some value. This value might be a simple
quantity, or it might denote another object. For example, part of the state of an elevator might
have the value 3, denoting the current floor on which the elevator is located. In the case of the
vending machine, its state encompasses many other objects, such as a collection of soft drinks.
The individual drinks are in fact distinct objects; their properties are different from those of the
machine (they can be consumed, whereas a vending machine cannot), and they can be operated
on in distinctly different ways. Thus, we distinguish between objects and simple values: Simple
quantities such as the number 3 are “atemporal, unchangeable, and non-instantiated,” whereas
objects “exist in time, are changeable, have state, are instantiated, and can be created, destroyed,
and shared” [6].
The fact that every object has state implies that every object takes up some amount of space, be it
in the physical world or in computer memory. We may say that all objects within a system
encapsulate some state and that all of the state within a system is encapsulated by objects.
Encapsulating the state of an object is a start, but it is not enough to allow us to capture the full
intent of the abstractions we discover and invent during development (refer to Example 3–1,
which shows how a simple abstraction may evolve). For this reason, we must also consider how
objects behave.

54
Example 3–1
Consider an abstraction of an employee record.
Figure 3–1 depicts this abstraction using the
Unified Modeling Language notation for a class.
(For more on the UML notation, see Chapter 5.)
Each part of this abstraction denotes a particular
property of our abstraction of an employee. This
abstraction is not an object because it does not
represent a specific instance. When made
specific, we may have, for example, two distinct
objects: Tom and Kaitlyn, each of which takes up some amount of space in memory (see Figure
3–2).
None of these objects shares its space with any
other object, although each of them has the same
properties; thus, their states have a common
representation. It is good engineering practice to
encapsulate the state of an object rather than
expose it. For example, we might change the
abstraction (class) as shown in Figure 3–3. This
abstraction is slightly more complicated than the
previous one, but it is superior for a number of
reasons. Specifically, its internal representation is
hidden (protected, indicated by #) from all other
outside clients. If we change its representation, we
will have to recompile some code, but
semantically, no outside client will be affected by
this change (in other words, existing code will not
break). Also, we have captured certain decisions
about the problem space by explicitly stating some
of the operations (responsibilities) that clients may
perform on objects of this class. In particular, we
grant all clients the (public, indicated by +) right
to retrieve the name, social security number, and
department of an employee. We will discuss
visibility (i.e., public, protected, private, and
package) later in this chapter.
Behavior
No object exists in isolation. Rather, objects are acted on and themselves act on other objects.
Thus, we may say the following: Behavior is how an object acts and reacts, in terms of its state
changes and message passing.
In other words, the behavior of an object represents its outwardly visible activity. An operation is
some action that one object performs on another in order to elicit a reaction. For example, a

55
client might invoke the operations append and pop to grow and shrink a queue object,
respectively. A client might also invoke the operation length, which returns a value denoting the
size of the queue object but does not alter the state of the queue itself.
In Java, operations that clients may perform on an object are typically declared as methods. In
languages such as C++, which derive from more procedural ancestors, we speak of one object
invoking the member function of another. In pure object-oriented languages such as Smalltalk,
we speak of one object passing a message to another. Generally, a message is simply an
operation that one object performs on another, although the underlying dispatch mechanisms are
different. For our purposes, the terms operation and message are interchangeable. Message
passing is one part of the equation that defines the behavior of an object; our definition for
behavior also notes that the state of an object affects its behavior as well. Consider again the
vending machine example. We may invoke some operation to make a selection, but the vending
machine will behave differently depending on its state. If we do not deposit change sufficient for
our selection, the machine will probably do nothing. If we provide sufficient change, the
machine will take our change and then give us our selection (thereby altering its state). Thus, we
may say that the behavior of an object is a function of its state as well as the operation performed
on it, with certain operations having the side effect of altering the object’s state. This concept of
side effect thus leads us to refine our definition of state.
The state of an object represents the cumulative results of its behavior. Most interesting objects
do not have state that is static; rather, their state has properties whose values are modified and
retrieved as the object is acted on. The behavior of an object is embodied in the sum of its
operations. Next we will discuss operations, how they relate to an object’s roles, and how they
enable objects to meet their responsibilities.
Operations
An operation denotes a service that a class offers to its clients. In practice, we have found that a
client typically performs five kinds of operations on an object.2 The three most common kinds of
operations are the following:
■ Modifier: an operation that alters the state of an object
■ Selector: an operation that accesses the state of an object but does not alter the state
■ Iterator: an operation that permits all parts of an object to be accessed in some well-defined
order
Two other kinds of operations are common; they represent the infrastructure necessary to create
and destroy instances of a class.
■ Constructor: an operation that creates an object and/or initializes its state
■ Destructor: an operation that frees the state of an object and/or destroys the object itself

56
In C++, constructors and destructors are declared as part of the definition of a class, whereas in
Java there are constructors, but no destructors. In Smalltalk, such operations are typically part of
the protocol of a metaclass (i.e., the class of a class).
Roles and Responsibilities
Collectively, all of the methods
associated with a particular object
comprise its protocol. The protocol of an
object thus defines the envelope of an
object’s allowable behavior and so
comprises the entire static and dynamic
view of the object. For most nontrivial
abstractions, it is useful to divide this
larger protocol into logical groupings of
behavior. These collections, which thus
partition the behavior space of an object,
denote the roles that an object can play. A
role is a mask that an object wears [8] and
so defines a contract between an
abstraction and its clients.
“Responsibilities are meant to convey a
sense of the purpose of an object and its place in the system. The responsibilities of an object are
all the services it provides for all of the contracts it supports” [9]. In other words, we may say
that the state and behavior of an object collectively define the roles that an object may play in the
world, which in turn fulfill the abstraction’s responsibilities. Indeed, most interesting objects
play many different roles during their lifetime. Consider the following examples [10].
■ A bank account may have the role of a monetary asset to which the account owner may deposit
or withdraw money. However, to a taxing authority, the account may play the role of an entity
whose dividends must be reported on annually.
■ To a trader, a share of stock represents an entity with value that may be bought or sold; to a
lawyer, the same share denotes a legal instrument to which are attached certain rights.
■ In the course of one day, the same person may play the role of mother, doctor, gardener, and
movie critic.
The roles played by objects are dynamic yet can be
mutually exclusive. In the case of the share of stock,
its roles overlap slightly, but each role is static
relative to the client that interacts with the share. In
the case of the person, her roles are quite dynamic
and may change from moment to moment. As we will
discuss further in later chapters, we often start our
analysis of a problem by examining the various roles

57
that an object plays. During design, we refine these roles by inventing the particular operations
that carry out each role’s responsibilities.
Objects as Machines
The existence of state within an object means that the order in which operations are invoked is
important. This gives rise to the idea that each object is like a tiny, independent machine [11].
Indeed, for some objects, this event and time ordering of operations is so pervasive that we can
best formally characterize the behavior of such objects in terms of an equivalent finite state
machine. In Chapter 5, we will show a particular notation for hierarchical finite state machines
that we may use for expressing these semantics.
Continuing the machine metaphor, we may classify objects as either active or passive. An active
object is one that encompasses its own thread of control, whereas a passive object does not.
Active objects are generally autonomous, meaning that they can exhibit some behavior without
being operated on by another object. Passive objects, on the other hand, can undergo a state
change only when explicitly acted on. In this manner, the active objects in our system serve as
the roots of control. If our system involves multiple threads of control, we will usually have
multiple active objects. Sequential systems, on the other hand, usually have exactly one active
object, such as a main object responsible for managing an event loop that dispatches messages.
In such architectures, all other objects are passive, and their behavior is ultimately triggered by
messages from the one active object. In other kinds of sequential system architectures (such as
transaction-processing systems), there is no obvious central active object, so control tends to be
distributed throughout the system’s passive objects.
Identity
Khoshafian and Copeland offer the following definition for identity: “Identity is that property of
an object which distinguishes it from all other objects” [12]. They go on to note that “most
programming and database languages use variable names to distinguish temporary objects,
mixing addressability and identity. Most database systems use identifier keys to distinguish
persistent objects, mixing data value and identity.” The failure to recognize the difference
between the name of an object and the object itself is the source of many kinds of errors in
objectoriented programming.
Example 3–2 demonstrates the importance of maintaining the identity of the objects you create
and shows how easily the identity can be irrecoverably lost.
Example 3–2
Consider a class that denotes a display item. A display item is a common abstraction in all GUI-
centric systems: It represents the base class of all objects that have a visual representation on
some window and so captures the structure and behavior common to all such objects. Clients
expect to be able to draw, select, and move display items, as well as query their selection state
and location. Each display item has a location designated by the coordinates x and y.

58
Let us assume we instantiate a number of
DisplayItem classes as indicated in Figure
3–4a. Specifically, the manner in which we
instantiate these classes sets aside four
locations in memory whose names are
item1, item2, item3, and item4, respectively.
Here, item1 is the name of a distinct
DisplayItem object, but the other three
names each denote a pointer to a
DisplayItem object. Only item2 and item3
actually point to distinct DisplayItem objects
(because in their declarations we allocated a
new DisplayItem object); item4 designates
no such object. Furthermore, the names of
the objects pointed to by item2 and item3 are
anonymous: We can refer to these distinct
objects only indirectly, via their pointer
value.
The unique identity (but not necessarily the
name) of each object is preserved over the
lifetime of the object, even when its state is
changed. This is like the Zen question about
a river: Is a river the same river from one
day to the next, even though the same water
never flows through it? For example, let’s move item1. We can access the object designated by
item2, get its location, and move item1 to that same location. Also, if we equate item4 to item3,
we can now reference the object designated by item3 by using item4 also. Using item4 we can
then move that object to a new location, say, X=38, Y=100. Figure 3–4b illustrates these results.
Here we see that item1 and the object designated by item2 both have the same location state and
that item4 now also designates the same object as does item3. Notice that we use the phrase “the
object designated by item2” rather than saying “the object item2.” The first phrase is more
precise, although we will sometimes use these phrases interchangeably.
Although item1 and the object designated by item2 have the same state, they represent distinct
objects. Also, note that we have changed the state of the object designated by item3 by operating
on it through its new indirect name, item4. This is a situation we call structural sharing, meaning
that a given object can be named in more than one way; in other words, there are aliases to the
object. Structural sharing is the source of many problems in object-oriented programming.
Failure to recognize the side effects of operating on an object through aliases often leads to
memory leaks, memory access violations, and, even worse, unexpected state changes. For
example, if we destroyed the object designated by item3, then item4’s pointer value would be
meaningless; this is a situation we call a dangling reference.
Consider also Figure 3–4c, which illustrates the results of modifying the value of the item2
pointer to point to item1. Now item2 designates the same object as item1. Unfortunately, we
have introduced a memory leak: The object originally designated by item2 can no longer be

59
named, either directly or indirectly, and so its identity is lost. In languages such as Smalltalk and
Java, such objects will be garbage-collected and their storage reclaimed automatically, but in
languages such as C++, their storage will not be reclaimed until the program that created them
finishes. Especially for long-running programs, memory leaks such as this are either bothersome
or disastrous.
Relationships among Objects
An object by itself is intensely uninteresting. Objects contribute to the behavior of a system by
collaborating with one another. “Instead of a bit-grinding processor raping and plundering data
structures, we have a universe of well-behaved objects that courteously ask each other to carry
out their various desires” [13]. For example, consider the object structure of an airplane, which
has been defined as “a collection of parts having an inherent tendency to fall to earth, and
requiring constant effort and supervision to stave off that outcome” [14]. Only the collaborative
efforts of all the component objects of an airplane enable it to fly. The relationship between any
two objects encompasses the assumptions that each makes about the other, including what
operations can be performed and what behavior results. We have found that two kinds of object
relationships are of particular interest in object-oriented analysis and design, namely:
1. Links
2. Aggregation
Links
The term link derives from Rumbaugh et al., who define it as a “physical or conceptual
connection between objects” [16]. An object collaborates with other objects through its links to
these objects. Stated another way, a link denotes the specific association through which one
object (the client) applies the services of another object (the supplier), or through which one
object may navigate to another. Figure 3–5 illustrates several different links. In this figure, a line
between two object icons represents the existence of a link between the two and means that
messages may pass along this path. Messages are shown as small directed lines representing the
direction of the message, with a label naming the message itself. For example, in Figure 3–5 we
show part of a simplified flow control system. This may be controlling the flow of water through
a pipe in a manufacturing plant. You can see that the FlowController object has a link to a Valve
object. The Valve object has a link to the DisplayPanel object in which its status will be
displayed. Only across these links may one object send messages to another.
Message passing between two objects is typically unidirectional, although it may occasionally be
bidirectional. In our example, the FlowController object invokes operations on the Valve object
(to change its setting) and the
DisplayPanel (to change what it displays), but these objects do not themselves operate on the
FlowController object. This separation of concerns is quite common in well-structured object-
oriented systems. Notice also that although message passing is initiated by the client (such as
FlowController) and is directed toward the supplier (such as the Valve object), data may flow in
either direction across a link. For example, when FlowController invokes the operation adjust on
the Valve object, data (i.e., the setting to change to) flows from the client to the supplier.

60
However, if FlowController invokes a different operation, isClosed, on the Valve object, the
result (i.e., whether the valve is in the fully closed position) passes from the supplier to the client.
As a participant in a link, an object may play one of three roles.
1. Controller: This object can operate on other
objects but is not operated on by other
objects. In some contexts, the terms active
object and controller are interchangeable.
2. Server: This object doesn’t operate on
other objects; it is only operated on by other
objects.
3. Proxy: This object can both operate on
other objects and be operated on by other
objects. A proxy is usually created to
represent a real-world object in the domain of
the application.
In the context of Figure 3–5, FlowController
acts as a controller object, DisplayPanel acts as a server object, and Valve acts as a proxy.
Example 3–3 illustrates how responsibilities can be properly separated across a group of
collaborating objects.
Example 3–3
In many different kinds of industrial processes, certain reactions require a temperature ramp,
wherein we raise the temperature of some substance, hold it at that temperature for a fixed
period, and then let it cool to ambient temperature. Different processes require different profiles:
Some objects (such as telescope mirrors) must be cooled slowly, whereas other materials (such
as steel) must be cooled rapidly. This abstraction of a temperature ramp has a sufficiently well-
defined behavior that it warrants the creation of a class. Thus we provide the class
TemperatureRamp, which is conceptually a time/temperature mapping (see Figure 3–6).
Actually, the behavior of this abstraction is more than just a literal time/ temperature mapping.
For example, we might set a temperature ramp that requires the temperature to be 250°F at time
60 (one hour into the temperature ramp) and 150°F at time 180 (three hours into the process), but
then we would like to know what the temperature should be at time 120. This requires linear
interpolation, which is therefore another behavior (i.e., interpolate) we expect of this abstraction.
One behavior we explicitly do not require of this abstraction is the control of a heater to carry out
a particular temperature ramp. Rather, we prefer a greater separation of concerns, wherein this
behavior is achieved through the collaboration of three objects: a temperature ramp instance, a
heater, and a temperature controller (see Figure 3–6). The operation process provides the central
behavior of this abstraction; its purpose is to carry out the given temperature ramp for the heater
at the given location. A comment regarding our style: At first glance, it may appear that we have
devised an abstraction whose sole purpose is to wrap a functional decomposition inside a class to
make it appear noble and object-oriented. The operation schedule suggests that this is not the

61
case. Objects of the class TemperatureController have sufficient knowledge to determine when a
particular profile should be scheduled, so we expose this operation as an additional behavior of
our abstraction. In some high-energy industrial processes (such as steel making), heating a
substance is a costly event, and it is important to take into account any lingering heat from a
previous process, as well as the normal cool-down of an unattended heater. The operation
schedule exists so that clients can query a TemperatureController object to determine the next
optimal time to process a particular temperature ramp.
Visibility
Consider two objects, A and B, with a link between the two. In order for A to send a message to
B, B must be visible to A in some manner. During our analysis of a problem, we can largely
ignore issues of visibility, but once we begin to devise concrete implementations, we must
consider the visibility across links because our decisions here dictate the scope and access of the
objects on each side of a link. We will discuss this further later in this chapter.
Synchronization
Whenever one object passes a message to another across a link, the two objects are said to be
synchronized. For objects in a completely sequential application, this synchronization is usually
accomplished by simple method invocation. However, in the presence of multiple threads of
control, objects require more sophisticated message passing in order to deal with the problems of
mutual exclusion that can occur in concurrent systems. As we described earlier, active objects
embody their own thread of control, so we expect their semantics to be guaranteed in the
presence of other active objects. However, when one active object has a link to a passive one, we
must choose one of three approaches to synchronization.
1. Sequential: The semantics of the passive object are guaranteed only in the presence of a single
active object at a time.
2. Guarded: The semantics of the passive object are guaranteed in the presence of multiple
threads of control, but the active clients must collaborate to achieve mutual exclusion.
3. Concurrent: The semantics of the passive object are guaranteed in the presence of multiple
threads of control, and the supplier guarantees mutual exclusion.
Aggregation
Whereas links denote peer-to-peer or client/supplier relationships, aggregation denotes a
whole/part hierarchy, with the ability
to navigate from the whole (also
called the aggregate) to its parts. In
this sense, aggregation is a
specialized kind of association. For
example, as shown in Figure 3–6, the
object Temperature- Controller has a
link to the object TemperatureRamp
as well as to Heater. The object

62
TemperatureController is thus the whole, and Heater is one of its parts. The notation shown for
an aggregation relationship will be further explained in Chapter 5.
By implication, an object that is a part of another object has a link to its aggregate. Across this
link, the aggregate may send messages to its parts. Given the object TemperatureController, it is
possible to find its corresponding Heater. Given an object such as Heater, it is possible to
navigate to its enclosing object (also called its container) if and only if this knowledge is a part
of the state of Heater.
Aggregation may or may not denote physical containment. For example, an airplane is composed
of wings, engines, landing gear, and so on: This is a case of physical containment. On the other
hand, the relationship between a shareholder and his or her shares is an aggregation relationship
that does not require physical containment. The shareholder uniquely owns shares, but the shares
are by no means a physical part of the shareholder. Rather, this whole/part relationship is more
conceptual and therefore less direct than the physical aggregation of the parts that form an
airplane.
There are clear trade-offs between links and aggregation. Aggregation is sometimes better
because it encapsulates parts as secrets of the whole. Links are sometimes better because they
permit looser coupling among objects. Intelligent engineering decisions require careful weighing
of these two factors.
3.3 The Nature of a Class
The concepts of a class and an object are tightly interwoven, for we cannot talk about an object
without regard for its class. However, there are important differences between these two terms.
What Is and What Isn’t a Class
Whereas an object is a concrete entity that exists in time and space, a class represents only an
abstraction, the “essence” of an object, as it were. Thus, we may speak of the class Mammal,
which represents the characteristics common to all mammals. To identify a particular mammal in
this class, we must speak of “this mammal” or “that mammal.”
In everyday terms, Webster’s Third New
International Dictionary defines a class as
“a group, set, or kind marked by common
attributes or a common attribute; a group
division, distinction, or rating based on
quality, degree of competence, or condition”
[17]. In the context of object-oriented
analysis and design, we define a class as
follows: A class is a set of objects that share
a common structure, common behavior, and
common semantics. A single object is
simply an instance of a class.

63
What isn’t a class? An object is not a class. Objects that share no common structure and behavior
cannot be grouped in a class because, by definition, they are unrelated except by their general
nature as objects. It is important to note that the class—as defined by most programming
languages— is a necessary but insufficient vehicle for decomposition. Sometimes abstractions
are so complex that they cannot be conveniently expressed in terms of a single class declaration.
For example, at a sufficiently high level of abstraction, a GUI framework, a database, and an
entire inventory system are all conceptually individual objects, none of which can be expressed
as a single class.4 Instead, it is far better for us to capture these abstractions as a cluster of
classes whose instances collaborate to provide the desired structure and behavior. Stroustrup
calls such a cluster a component [18].
Interface and Implementation
Meyer [19] and Snyder [20] have both suggested that programming is largely a matter of
“contracting”: The various functions of a larger problem are decomposed into smaller problems
by subcontracting them to different elements of the design. Nowhere is this idea more evident
than in the design of classes. Whereas an individual object is a concrete entity that performs
some role in the overall system, the class captures the structure and behavior common to all
related objects. Thus, a class serves as a sort of binding contract between an abstraction and all
of its clients. By capturing these decisions in the interface of a class, a strongly typed
programming language can detect violations of this contract during compilation.
This view of programming as contracting leads us to distinguish between the outside view and
the inside view of a class. The interface of a class provides its outside view and therefore
emphasizes the abstraction while hiding its structure and the secrets of its behavior. This
interface primarily consists of the declarations of all the operations applicable to instances of this
class, but it may also include the declaration of other classes, constants, variables, and exceptions
as needed to complete the abstraction. By contrast, the implementation of a class is its inside
view, which encompasses the secrets of its behavior. The implementation of a class primarily
consists of the implementation of all of the operations defined in the interface of the class.
We can further divide the interface of a class into four parts:
1. Public: a declaration that is accessible to all clients
2. Protected: a declaration that is accessible only to the class itself and its subclasses
3. Private: a declaration that is accessible only to the class itself
4. Package: a declaration that is accessible only by classes in the same package
The detailed semantics of these forms of visibility can vary based on the implementation
language used. The constants and variables that form the representation of a class are known by
various terms, depending on the particular language we use. For example, Smalltalk uses the
term instance variable, Object Pascal and Java use the term field, C++ uses the term data
member. We will use these terms interchangeably to denote the parts of a class that serve as the
representation of its instance’s state. The state of an object must have some representation in its
corresponding class and so is typically expressed as constant and variable declarations placed in

64
the protected or private part of a class’s interface. In this manner, the representation common to
all instances of a class is encapsulated, and changes to this representation do not functionally
affect any outside clients.
Class Lifecycle
We may come to understand the behavior of a simple class just by understanding the semantics
of its distinct public operations in isolation. However, the behavior of more interesting classes
(such as moving an instance of the class DisplayItem or scheduling an instance of the class
TemperatureController) involves the interaction of their various operations over the lifetime of
each of their instances. As described earlier in this chapter, the instances of such classes act as
little machines, and since all such instances embody the same behavior, we can use the class to
capture these common event- and time-ordered semantics. As we discuss in Chapter 5, we may
describe such dynamic behavior for certain interesting classes by using finite state machines.
3.4 Relationships among Classes
Consider for a moment the similarities and differences among the following classes of objects:
flowers, daisies, red roses, yellow roses, petals, and ladybugs.
We can make the following observations.
■ A daisy is a kind of flower.
■ A rose is a (different) kind of flower.

65
■ Red roses and yellow roses are both kinds of roses.
■ A petal is a part of both kinds of flowers.
■ Ladybugs eat certain pests such as aphids, which may be infesting certain kinds of flowers.
From this simple example we conclude that classes, like objects, do not exist in isolation. Rather,
for a particular problem domain, the key abstractions are usually related in a variety of
interesting ways, forming the class structure of our design [21].
We establish relationships between two classes for one of two reasons. First, a class relationship
might indicate some sort of sharing. For example, daisies and roses are both kinds of flowers,
meaning that both have brightly colored petals, both emit a fragrance, and so on. Second, a class
relationship might indicate some kind of semantic connection. Thus, we say that red roses and
yellow roses are more alike than are daisies and roses, and daisies and roses are more closely
related than are petals and flowers. Similarly, there is a symbiotic connection between ladybugs
and flowers: Ladybugs protect flowers from certain pests, which in turn serve as a food source
for the ladybug.
In all, there are three basic kinds of class relationships [22]. The first of these is
generalization/specialization, denoting an “is a” relationship. For instance, a rose is a kind of
flower, meaning that a rose is a specialized subclass of the more general class, flower. The
second is whole/part, which denotes a “part of” relationship. Thus, a petal is not a kind of a
flower; it is a part of a flower. The third is association, which denotes some semantic dependency
among otherwise unrelated classes, such as between ladybugs and flowers. As another example,
roses and candles are largely independent classes, but they both represent things that we might
use to decorate a dinner table.
Association
Of these different kinds of class relationships, associations are the most general but also the most
semantically weak. The identification of associations among classes is often an activity of
analysis and early design, at which time we begin to discover the general dependencies among
our abstractions. As we continue our design and implementation, we will often refine these weak
associations by turning them into one of the other more concrete class relationships.
Semantic Dependencies
As Example 3–4 suggests, an association only denotes a semantic dependency and does not state
the direction of this dependency (unless otherwise stated, an association implies bidirectional
navigation, as in our example), nor does it state the exact way in which one class relates to
another (we can only imply these semantics by naming the role each class plays in relationship
with the other). However, these semantics are sufficient during the analysis of a problem, at
which time we need only to identify such dependencies. Through the creation of associations, we
come to capture the participants in a semantic relationship, their roles, and their cardinality.

66
Example 3–4
For a vehicle, two of our key
abstractions include the vehicle and
wheels. As shown in Figure 3–7, we
may show a simple association
between these two classes: the class
Wheel and the class Vehicle.
(Arguably, an aggregation would be
better.) By implication, this association
suggests bidirectional navigation.
Given an instance of Wheel, we should be able to locate the object denoting its Vehicle, and
given an instance of Vehicle, we should be able to locate all the wheels.
Multiplicity
Our example introduced a one-to-many association, meaning that for each instance of the class
Vehicle, there are zero (a boat, which is a vehicle, has no wheels) or more instances of the class
Wheel, and for each Wheel, there is exactly one Vehicle. This denotes the multiplicity of the
association. In practice, there are three common kinds of multiplicity across an association:
1. One-to-one
2. One-to-many
3. Many-to-many
A one-to-one relationship denotes a very
narrow association. For example, in retail
telemarketing operations, we would find a
one-to-one relationship between the class
Sale and the class CreditCardTransaction:
Each sale has exactly one corresponding
credit card transaction, and each such
transaction corresponds to one sale. Many-to-
many relationships are also common. For
example, each instance of the class Customer
might initiate a transaction with several
instances of the class SalesPerson, and each
such salesperson might interact with many
different customers. As we will discuss
further in Chapter 5, there are variations on
these three common forms of multiplicity.

67
Inheritance
Inheritance, perhaps the most semantically interesting of these concrete relationships, exists to
express generalization/specialization relationships. In our experience, however, inheritance is an
insufficient means of expressing all of the rich relationships that may exist among the key
abstractions in a given problem domain. An alternate approach to inheritance involves a
language mechanism called delegation, in which objects delegate their behavior to related
objects.
Example 3–5
After space probes are launched, they report back to ground stations with information regarding
the status of important subsystems (such as electrical power and propulsion systems) and
different sensors (such as radiation sensors, mass spectrometers, cameras, micrometeorite
collision detectors, and so on). Collectively, this relayed information is called telemetry data.
Telemetry data is commonly transmitted as a bitstream consisting of a header, which includes a
timestamp and some keys identifying the kind of information that follows, plus several frames of
processed data from the various subsystems and sensors. This appears to be a straightforward
aggregation of different kinds of data.
This critical data needs to be encapsulated. Otherwise, there is nothing to prevent a client from
changing the value of important data such as timestamp or currentPower. Likewise, the
representation of this data is exposed, so if we were to change the representation (e.g., by adding
new elements or changing the bit alignment of existing ones), every client would be affected. At
the very least, we would certainly have to recompile every reference to this structure.
More importantly, such changes might violate the assumptions that clients had made about this
representation and cause the logic in our program to break. Lastly, suppose our analysis of the
system’s requirements reveals the need for several hundred different kinds of telemetry data,
including electrical data that encompassed the preceding information and also included voltage
readings from various test points throughout the system. We would find that declaring these
additional structures would create a
considerable amount of redundancy,
in terms of both replicated structures
and common functions.
A slightly better way to capture our
decisions would be to declare one
class for each kind of telemetry data.
In this manner, we could hide the
representation of each class and
associate its behavior with its data.
Still, this approach does not address
the problem of redundancy. A far
better solution, therefore, is to
capture our decisions by building a
hierarchy of classes, in which

68
specialized classes inherit the structure and behavior defined by more generalized classes, as
shown in Figure 3–8.
Single Inheritance
Simply stated, inheritance is a relationship among classes wherein one class shares the structure
and/or behavior defined in one (single inheritance) or more (multiple inheritance) other classes.
We call the class from which another class inherits its superclass. In Example 3–5,
TelemetryData is a superclass of ElectricalData. Similarly, we call a class that inherits from one
or more classes a subclass; ElectricalData is a subclass of TelemetryData. Inheritance therefore
defines an “is a” hierarchy among classes, in which a subclass inherits from one or more
superclasses. This is in fact the litmus test for inheritance. Given classes A and B, if A is not a
kind of B, then A should not be a subclass of B. In this sense, ElectricalData is a specialized kind
of the more generalized class TelemetryData. The ability of a language to support this kind of
inheritance distinguishes object-oriented from object-based programming languages.
A subclass typically augments or restricts the existing structure and behavior of its superclasses.
A subclass that augments its superclasses is said to use inheritance for extension. For example,
the subclass GuardedQueue might extend the behavior of its superclass Queue by providing extra
operations that make instances of this class safe in the presence of multiple threads of control. In
contrast, a subclass that constrains the behavior of its superclasses is said to use inheritance for
restriction. For example, the subclass UnselectableDisplayItem might constrain the behavior of
its superclass, DisplayItem, by prohibiting clients from selecting its instances in a view. In
practice, it is not always so clear whether or not a subclass augments or restricts its superclass; in
fact, it is common for a subclass to do both.
Figure 3–9 illustrates the single
inheritance relationships deriving from
the superclass TelemetryData. Each
directed line denotes an “is a”
relationship. For example, CameraData
“is a” kind of SensorData, which in
turn “is a” kind of TelemetryData. This
is identical to the hierarchy one finds
in a semantic net, a tool often used by
researchers in cognitive science and
artificial intelligence to organize
knowledge about the world [25].
Indeed, as we discuss further in
Chapter 4, designing a suitable
inheritance hierarchy among
abstractions is largely a matter of
intelligent classification.
We expect that some of the classes in
Figure 3–9 will have instances and
some will not. For example, we expect

69
to have instances of each of the most specialized classes (also known as leaf classes or concrete
classes), such as ElectricalData and SpectrometerData. However, we are not likely to have any
instances of the intermediate, more generalized classes, such as SensorData or even
TelemetryData. Classes with no instances are called abstract classes. An abstract class is written
with the expectation that its subclasses will add to its structure and behavior, usually by
completing the implementation of its (typically) incomplete methods.
There is a very real tension between inheritance and encapsulation. To a large degree, the use of
inheritance exposes some of the secrets of an inherited class. Practically, this means that to
understand the meaning of a particular class, you must often study all of its superclasses,
sometimes including their inside views. Inheritance means that subclasses inherit the structure of
their superclass. Thus, in Example 3–5, the instances of the class ElectricalData include the data
members of the superclass (such as id and timestamp), as well as those of the more specialized
classes (such as fuelCell1Voltage, fuelCell2Voltage, fuelCell1Amperes, and fuelCell2Amperes).
Polymorphism
For the class TelemetryData, the function transmit may transmit the identifier of the telemetry
stream and its timestamp. But the same function for the class ElectricalData may invoke the
TelemetryData transmit function and also transmit its voltage and current values. This behavior
is due to polymorphism. In a generalization, such operations are called polymorphic.
Polymorphism is a concept in type theory wherein a name may denote instances of many
different classes as long as they are related by some common superclass. Any object denoted by
this name is thus able to respond to some common set of operations in different ways. With
polymorphism, an operation can be implemented differently by the classes in the hierarchy. In
this manner, a subclass can extend the capabilities of its superclass or override the parent’s
operation, as ElectricalData does in Example 3–5. The concept of polymorphism was first
described by Strachey [29], who spoke of ad hoc polymorphism, by which symbols such as +
could be defined to mean different things. We call this concept overloading. In C++, one may
declare functions having the same names, as long as their invocations can be distinguished by
their signatures, consisting of the number and types of their arguments (in C++, unlike Ada, the
type of a function’s returned value is not considered in overload resolution). By contrast, Java
does not permit overloaded operators.
Strachey also spoke of parametric polymorphism, which today we simply call polymorphism.
Without polymorphism, the developer ends up writing code consisting of large case or switch
statements.6 Without it, we cannot create a hierarchy of classes for the various kinds of telemetry
data; rather, we have to define a single, monolithic variant record encompassing the properties
associated with all the kinds of data. To distinguish one variant from another, we have to
examine the tag associated with the record. To add another kind of telemetry data, we would
have to modify the variant record and add it to every case statement that operated on instances of
this record. This is particularly error-prone and, furthermore, adds instability to the design. In the
presence of inheritance, there is no need for a monolithic type since we may separate different
kinds of abstractions. As Kaplan and Johnson note, “Polymorphism is most useful when there are
many classes with the same protocols” [30]. With polymorphism, large case statements are
unnecessary because each object implicitly knows its own type. Inheritance without
polymorphism is possible, but it is certainly not very useful. Polymorphism and late binding go

70
hand in hand. In the presence of polymorphism, the binding of a method to a name is not
determined until execution. In C++, the developer may control whether a member function uses
early or late binding. Specifically, if the method is declared as virtual, then late binding is
employed, and the function is considered to be polymorphic. If this virtual declaration is omitted,
then the method uses early binding and thus can be resolved at the time of compilation. Java
simply performs late binding without the need for an explicit declaration such as virtual. How an
implementation selects a particular method for execution is described in the sidebar, Invoking a
Method.
Invoking a Method
In traditional programming
languages, invoking a subprogram
is a completely static activity. In
Pascal, for example, for a statement
that calls the subprogram P, a
compiler will typically generate
code that creates a new stack frame,
places the proper arguments on the
stack, and then changes the flow of
control to begin executing the code
associated with P. However, in
languages that support some form
of polymorphism, such as Smalltalk
and C++, invoking an operation
may require a dynamic activity
because the class of the object being
operated on may not be known until
runtime. Matters are even more
interesting when we add inheritance
to the situation. The semantics of invoking an operation in the presence of inheritance without
polymorphism is largely the same as for a simple static subprogram call, but in the presence of
polymorphism, we must use a much more sophisticated technique. Consider the class hierarchy
in Figure 3–10, which shows the base class DisplayItem along with three subclasses named
Circle, Triangle, and Rectangle. Rectangle also has one subclass, named SolidRectangle. In the
class DisplayItem, suppose that we define the instance variable theCenter (denoting the
coordinates for the center of the displayed item), along with the following operations as in our
earlier example:
■ draw Draw the item.
■ move Move the item.
■ location Return the location of the item.

71
The operation location is common to all subclasses and therefore need not be redefined, but we
expect the operations draw and move to be redefined since only the subclasses know how to
draw and move themselves.
The class Circle must include the instance variable theRadius and appropriate operations to set
and retrieve its value. For this subclass, the redefined operation draw draws a circle of the given
radius, centered on theCenter. Similarly, the class Rectangle must include the instance variables
theHeight and theWidth, along with appropriate operations to set and retrieve their values. For
this subclass, the operation draw draws a rectangle with the given height and width, again
centered on theCenter. The subclass SolidRectangle inherits all characteristics of the class
Rectangle but again redefines the behavior of the operation draw. Specifically, the
implementation of draw for the class SolidRectangle first calls draw as defined in its superclass
Rectangle (to draw the outline of the rectangle) and then fills in the shape. The invocation of
draw demands polymorphic behavior.
Suppose now that we have some client object that wishes to draw all of the subclasses. In this
situation, the compiler cannot statically generate code to invoke the proper draw operation
because the class of the object being operated on is not known until runtime. Let’s consider how
various objectoriented programming languages deal with this situation. Because Smalltalk is a
typeless language, method dispatch is completely dynamic. When the client sends the message
draw to an item found in the list, here is what happens.
■ The item object looks up the message in its class’s message dictionary.
■ If the message is found, the code for that locally defined method is invoked.
■ If the message is not found, the search for the method continues in the superclass.
This process continues up the superclass hierarchy until the message is found or until we reach
the topmost base class, Object, without finding the message. In the latter case, Smalltalk
ultimately passes the message doesNotUnderstand to signal an error.
The key to this algorithm is the message dictionary, which is part of each class’s representation
and is therefore hidden from the client. This dictionary is created when the class is created and
contains all the methods to which instances of this class may respond. Searching for the message
is time-consuming; method lookup in Smalltalk takes about 1.5 times as long as a simple
subprogram call. All production-quality Smalltalk implementations optimize method dispatch by
supplying a cached message dictionary, so that commonly passed messages may be invoked
quickly. Caching typically improves performance by 20% to 30% [31]. The operation draw
defined in the subclass SolidRectangle poses a special case. We said that its implementation of
draw first calls draw as defined in the superclass Rectangle. In Smalltalk, we specify a
superclass method by using the keyword super. Then, when we pass the message draw to super,
Smalltalk uses the same method-dispatch algorithm as mentioned earlier, except that the search
begins in the superclass of the object instead of its class.
Studies by Deutsch suggest that polymorphism is not needed about 85% of the time, so message
passing can often be reduced to simple procedure calls [32]. Duff notes that in such cases, the
developer often makes implicit assumptions that permit an early binding of the object’s class

72
[33]. Unfortunately, typeless languages such as Smalltalk have no convenient means for
communicating these implicit assumptions to the compiler. More strongly typed languages such
as C++ do let the developer assert such information. Because we want to avoid method dispatch
wherever possible but must still allow for the occurrence of polymorphic dispatch, invoking a
method in these languages proceeds a little differently than in Smalltalk. In C++, the developer
can decide whether a particular operation is to be bound late by declaring it to be virtual; all
other methods are considered to be bound early, and thus the compiler can statically resolve the
method call to a simple subprogram call.
To handle virtual member functions, most C++ implementations use the concept of a vtable,
which is defined for each object requiring polymorphic dispatch, when the object is created (and
thus when the class of the object is fixed). This table typically consists of a list of pointers to
virtual functions. For example, if we create an object of the class Rectangle, then the table will
have an entry for the virtual function draw, pointing to the closest implementation of draw. If, for
example, the class DisplayItem included the virtual function Rotate, which was not redefined in
the class Rectangle, then the vtable entry for Rotate would point to the implementation of Rotate
in the class DisplayItem. In this manner, runtime searching is eliminated: Referring to a virtual
member function of an object is just an indirect reference through the appropriate pointer, which
immediately invokes the correct code without searching [34].
Multiple Inheritance
With single inheritance, each subclass has exactly one superclass. However, as Vlissides and
Linton point out, although single inheritance is very useful, “it often forces the programmer to
derive from one of two equally attractive classes. This limits the applicability of predefined
classes, often making it necessary to duplicate code. For example, there is no way to derive a
graphic that is both a circle and a picture; one must derive from one or the other and reimplement
the functionality of the class that was excluded” [40]. Consider for a moment how one might
organize various assets such as savings accounts, real estate, stocks, and bonds. Savings accounts
and checking accounts are both kinds of assets typically managed by a bank, so we might
classify both of them as kinds of bank accounts, which in turn are kinds of assets. Stocks and
bonds are managed quite differently than bank accounts, so we might classify stocks, bonds,
mutual funds, and the like as kinds of securities, which in turn are also kinds of assets. However,
there are many other equally satisfactory ways to classify savings accounts, real estate, stocks,
and bonds. For example, in some contexts, it may be useful to distinguish insurable items such as
real estate and certain bank accounts (which, in the United States, are insured up to certain limits
by the Federal Deposit Insurance Corporation). It may also be useful to identify assets that return
a dividend or interest, such as savings accounts, checking accounts, and certain stocks and bonds.
Unfortunately, single inheritance is not expressive enough to capture this lattice of relationships,
so we must turn to multiple inheritance.7 Figure 3–11 illustrates such a class structure. Here we
see that the class Security is a kind of Asset as well as a kind of InterestBearingItem. Similarly,
the class BankAccount is a kind of Asset, as well as a kind of InsurableItem and
InterestBearingItem.
Designing a suitable class structure involving inheritance, and especially involving multiple
inheritance, is a difficult task. This is often an incremental and iterative process. Two problems

73
present themselves when we have multiple inheritance: How do we deal with name collisions
from different superclasses, and how do we handle repeated inheritance? Name collisions are
possible when two or more different superclasses use the same name for some element of their
interfaces, such as instance variables and methods. For example, suppose that the classes
InsurableItem and Asset both have attributes named presentValue, denoting the present value of
the item. Since the class RealEstate inherits from both of these classes, what does it mean to
inherit two operations with the same name? This in fact is the key difficulty with multiple
inheritance: Clashes may introduce ambiguity in the behavior of the multiply inherited subclass.
There are three basic approaches to resolving this kind of clash. First, the language semantics
might regard such a clash as illegal and reject the compilation of the class. Second, the language
semantics might regard the same name introduced by different classes as referring to the same
attribute. Third, the language semantics might permit the clash but require that all references to
the name fully qualify the source of its declaration.
The second problem is repeated inheritance, which Meyer describes as follows: “One of the
delicate problems raised by the presence of multiple inheritance is what happens when a class is
an ancestor of another in more than one way. If you allow multiple inheritance into a language,
then sooner or later someone is going to write a class D with two parents B and C, each of which
has a class A as a parent— or some other situation in which D inherits twice (or more) from A.
This situation is called repeated
inheritance and must be dealt with
properly” [41]. As an example,
suppose that we define the (ill-
conceived) MutualFund class as a
subclass of the classes Stock and
Bond. This class introduces
repeated inheritance of the class
Security, which is a superclass of
both Stock and Bond (see Figure
3–11). There are various
approaches to dealing with the
problem of repeated inheritance.
First, we can treat occurrences of
repeated inheritance as illegal.
Second, we can permit duplication
of superclasses but require the use
of fully qualified names to refer to
members of a specific copy. Third,
we can treat multiple references to
the same class as denoting the
same class. Different languages
handle this approach differently.
The existence of multiple
inheritance gives rise to a style of
classes called mixins. Mixins

74
derive from the programming culture surrounding the language Flavors: One would combine
(mix in) little classes to build classes with more sophisticated behavior. “A mixin is syntactically
identical to a regular class, but its intent is different. The purpose of such a class is solely to . . .
[add] functions to other flavors [classes]—one never creates an instance of a mixin” [44]. In
Figure 3–11, the classes InsurableItem and InterestBearingItem are mixins. Neither of these
classes can stand alone; rather, they are used to augment the meaning of some other class. Thus,
we may define a mixin as a class that embodies a single, focused behavior and is used to
augment the behavior of some other class via inheritance. The behavior of a mixin is usually
completely orthogonal to the behavior of the classes with which it is combined. A class that is
constructed primarily by inheriting from mixins and does not add its own structure or behavior is
called an aggregate class.
Aggregation
We also need aggregation relationships,
which provide the whole/part relationships
manifested in the class’s instances.
Aggregation relationships among classes
have a direct parallel to aggregation
relationships among the objects corresponding to these classes. As we show in Figure 3–12, the
class TemperatureController denotes the whole, and the class Heater is one of its parts. This
corresponds exactly to the aggregation relationship among the instances of these classes
illustrated earlier in Figure 3–6.
Physical Containment
In the case of the class TemperatureController, we have aggregation as containment by value, a
kind of physical containment meaning that the Heater object does not exist independently of its
enclosing TemperatureController instance. Rather, the lifetimes of these two objects are
intimately connected: When we create an instance of TemperatureController, we also create an
instance of the class Heater. When we destroy our TemperatureController object, by implication
we also destroy the corresponding Heater object. A less direct kind of aggregation is also
possible, called composition, which is containment by reference. In this case, the class
TemperatureController still denotes the whole, and an instance of the class Heater is still one of
its parts, although that part must now be accessed indirectly. Hence, the lifetimes of these two
objects are not so tightly coupled as before: We may create and destroy instances of each class
independently. Aggregation asserts a direction to the whole/part relationship. For example, the
Heater object is a part of the TemperatureController object, and not vice versa. Of course, as we
described in an earlier example, aggregation need not require physical containment. For
example, although shareholders own stocks, a shareholder does not physically contain the owned
stocks. Rather, the lifetimes of these objects may be completely independent, although there is
still conceptually a whole/part relationship (each share is always a part of the shareholder’s
assets). Representation of this aggregation can be very indirect. This is still aggregation, although
not physical containment. Ultimately, the litmus test for aggregation is this: If and only if there
exists a whole/part relationship between two objects, we must have an aggregation relationship
between their corresponding classes.

75
Multiple inheritance is often confused with aggregation. When considering inheritance versus
aggregation, remember to apply the litmus test for each. If you cannot honestly affirm that there
is an “is a” relationship between two classes, aggregation or some other relationship should be
used instead of inheritance.
Dependencies
Aside from inheritance, aggregation, and association, there is another group of relationships
called dependencies. A dependency indicates that an element on one end of the relationship, in
some manner, depends on the element on the other end of the relationship. This alerts the
designer that if one of these elements changes, there could be an impact to the other. There are
many different kinds of dependency relationships (refer to the Object Management Group’s
latest UML specification for the full list [45]). You will often see dependencies used in
architectural models (one system component, or package, is dependent on another) or at the
implementation level (one module is dependent on another).
The Interplay of Classes and Objects
Classes and objects are separate yet intimately related concepts. Specifically, every object is the
instance of some class, and every class has zero or more instances. For practically all
applications, classes are static; therefore, their existence, semantics, and relationships are fixed
prior to the execution of a program. Similarly, the class of most objects is static, meaning that
once an object is created, its class is fixed. In sharp contrast, however, objects are typically
created and destroyed at a furious rate during the lifetime of an application.
Relationships between Classes and Objects
For example, consider the classes and objects in the implementation of an air traffic control
system. Some of the more important abstractions include planes, flight plans, runways, and air
spaces. By their very definition, the meanings of these classes and objects are relatively static.
They must be static, for otherwise one could not build an application that embodied knowledge
of such commonsense facts as that planes can take off, fly, and then land, and that two planes
should not occupy the same space at the same time. Conversely, the instances of these classes are
dynamic. At a fairly slow rate, new runways are built, and old ones are deactivated. Faster yet,
new flight plans are filed, and old ones are filed away. With great frequency, new planes enter a
particular air space, and old ones leave.
The Role of Classes and Objects in Analysis and Design
During analysis and the early stages of design, the developer has two primary tasks:
1. Identify the classes that form the vocabulary of the problem domain
2. Invent the structures whereby sets of objects work together to provide the behaviors that
satisfy the requirements of the problem Collectively, we call such classes and objects the key
abstractions of the problem, and we call these cooperative structures the mechanisms of the
implementation.

76
During these phases of development, the developer must focus on the outside view of these key
abstractions and mechanisms. This view represents the logical framework of the system and
therefore encompasses the class structure and object structure of the system. In the later stages of
design and then moving into implementation, the task of the developer changes: The focus is on
the inside view of these key abstractions and mechanisms, involving their physical
representation.
On Building Quality Classes and Objects
Ingalls suggests that “a system should be built with a minimum set of unchangeable parts; those
parts should be as general as possible; and all parts of the system should be held in a uniform
framework” [51]. With object-oriented development, these parts are the classes and objects that
make up the key abstractions of the system, and the framework is provided by its mechanisms.
In our experience, the design of classes and objects is an incremental, iterative process. Frankly,
except for the most trivial abstractions, we have never been able to define a class exactly right
the first time. It takes time to smooth the conceptual jagged edges of our initial abstractions. Of
course, there is a cost to refining these abstractions, in terms of recompilation, understandability,
and the integrity of the fabric of our system design. Therefore, we want to come as close as we
can to being right the first time.
Measuring the Quality of an Abstraction
How can one know if a given class or object is well designed? We suggest five meaningful
metrics:
1. Coupling
2. Cohesion
3. Sufficiency
4. Completeness
5. Primitiveness
Coupling is a notion borrowed from structured design, but with a liberal interpretation it also
applies to object-oriented design. Stevens, Myers, and Constantine define coupling as “the
measure of the strength of association established by a connection from one module to another.
Strong coupling complicates a system since a module is harder to understand, change, or correct
by itself if it is highly interrelated with other modules. Complexity can be reduced by designing
systems with the weakest possible coupling between modules” [52]. A counterexample to good
coupling is given by Page-Jones in his description of a modular stereo system in which the power
supply is located in one of the speaker cabinets [53].
Coupling with regard to modules still applies to object-oriented analysis and design, but coupling
with regard to classes and objects is equally important. However, there is tension between the
concepts of coupling and inheritance because inheritance introduces significant coupling. On the

77
one hand, weakly coupled classes are desirable; on the other hand, inheritance—which tightly
couples superclasses and their subclasses—helps us to exploit the commonality among
abstractions.
The idea of cohesion also comes from structured design. Simply stated, cohesion measures the
degree of connectivity among the elements of a single module (and for object-oriented design, a
single class or object). The least desirable form of cohesion is coincidental cohesion, in which
entirely unrelated abstractions are thrown into the same class or module. For example, consider a
class comprising the abstractions of dogs and spacecraft, whose behaviors are quite unrelated.
The most desirable form of cohesion is functional cohesion, in which the elements of a class or
module all work together to provide some well-bounded behavior. Thus, the class Dog is
functionally cohesive if its semantics embrace the behavior of a dog, the whole dog, and nothing
but the dog.
Closely related to the ideas of coupling and cohesion are the criteria that a class or module
should be sufficient, complete, and primitive. By sufficient, we mean that the class or module
captures enough characteristics of the abstraction to permit meaningful and efficient interaction.
To do otherwise renders the component useless. For example, if we are designing the class Set, it
is wise to include an operation that removes an item from the set, but our wisdom is futile if we
neglect an operation that adds an item. In practice, violations of this characteristic are detected
very early; such shortcomings rise up almost every time we build a client that must use this
abstraction.
By complete, we mean that the interface of the class or module captures all of the meaningful
characteristics of the abstraction. Whereas sufficiency implies a minimal interface, a complete
interface is one that covers all aspects of the abstraction. A complete class or module is thus one
whose interface is general enough to be commonly usable to any client. Completeness is a
subjective matter, and it can be overdone. Providing all meaningful operations for a particular
abstraction overwhelms the user and is generally unnecessary since many high-level operations
can be composed from low-level ones. For this reason, we also suggest that classes and modules
be primitive.
Primitive operations are those that can be efficiently implemented only if given access to the
underlying representation of the abstraction. Thus, adding an item to a set is primitive because to
implement this operation Add, the underlying representation must be visible. On the other hand,
an operation that adds four items to a set is not primitive because it can be implemented just as
efficiently on the more primitive Add operation, without having access to the underlying
representation. Of course, efficiency is also a subjective measure. An operation is indisputably
primitive if we can implement it only through access to the underlying representation. An
operation that could be implemented on top of existing primitive operations, but at the cost of
significantly more computational resources, is also a candidate for inclusion as a primitive
operation.
Choosing Operations
Crafting the interface of a class or module is plain hard work. Typically, we make a first attempt
at the design of a class, and then, as we and others create clients, we find it necessary to

78
augment, modify, and further refine this
interface. Eventually, we may discover patterns
of operations or patterns of abstractions that
lead us to invent new classes or to reorganize
the relationships among existing ones.
Functional Semantics
Within a given class, it is our style to keep all operations primitive, so that each exhibits a small,
well-defined behavior. We call such methods fine-grained. We also tend to separate methods that
do not communicate with one another. In this manner, it is far easier to construct subclasses that
can meaningfully redefine the behavior of their superclasses. The decision to contract out a
behavior to one versus many methods may be made for two competing reasons: Lumping a
particular behavior in one method leads to a simpler interface but larger, more complicated
methods; spreading a behavior across methods leads to a more complicated interface but simpler
methods. As Meyer observes, “A good designer knows how to find the appropriate balance
between too much contracting, which produces fragmentation, and too little, which yields
unmanageably large modules” [54].
It is common in object-oriented development to design the methods of a class as a whole because
all these methods cooperate to form the entire protocol of the abstraction. Thus, given some
desired behavior, we must decide in which class to place it. Halbert and O’Brien offer the
following criteria to be considered when making such a decision [55].
■ Reusability: Would this behavior be more useful in more than one context?
■ Complexity: How difficult is it to implement the behavior?
■ Applicability: How relevant is the behavior to the type in which it might be placed?
■ Implementation knowledge: Does the behavior’s implementation depend on the internal details
of a type?
We usually choose to declare the meaningful operations that we may perform on an object as
methods in the definition of that object’s class (or superclass).
Time and Space Semantics
Once we have established the existence of a particular operation and defined its functional
semantics, we must decide on its time and space semantics. This means that we must specify our
decisions about the amount of time it takes to complete an operation and the amount of storage it
needs. Such decisions are often expressed in terms of best, average, and worst cases, with the
worst case specifying an upper limit on what is acceptable. Earlier, we also mentioned that
whenever one object passes a message to another across a link, the two objects must be
synchronized in some manner. In the presence of multiple threads of control, this means that
message passing is much more than a subprogram-like dispatch. In most of the languages we
use, synchronization among objects is simply not an issue because our programs contain exactly
one thread of control, meaning that all objects are sequential. We speak of message passing in

79
such situations as simple because its semantics are most akin to simple subprogram calls.
However, in languages that support concurrency, we must concern ourselves with more
sophisticated forms of message passing, so as to avoid the problems created if two threads of
control act on the same object in unrestrained ways. As we described earlier, objects whose
semantics are preserved in the presence of multiple threads of control are either guarded or
synchronized objects.
Choosing Relationships
Choosing the relationships among classes and among objects is linked to the selection of
operations. If we decide that object X sends message M to object Y, then either directly or
indirectly, Y must be accessible to X; otherwise, we could not name the operation M in the
implementation of X. By accessible, we mean the ability of one abstraction to see another and
reference resources in its outside view. Abstractions are accessible to one another only where
their scopes overlap and only where access rights are granted (e.g., private parts of a class are
accessible only to the class itself and its friends). Coupling is thus a measure of the degree of
accessibility.
The Law of Demeter
One useful guideline in choosing the relationships among objects is called the Law of Demeter,
which states that “the methods of a class should not depend in any way on the structure of any
class, except the immediate (top-level) structure of their own class. Further, each method should
send messages to objects belonging to a very limited set of classes only” [56]. The basic effect of
applying this law is the creation of loosely coupled classes, whose implementation secrets are
encapsulated. Such classes are fairly unencumbered, meaning that to understand the meaning of
one class, you need not understand the details of many other classes.
In looking at the class structure of an entire system, we may find that its inheritance hierarchy is
wide and shallow, narrow and deep, or balanced. Class structures that are wide and shallow
usually represent forests of free-standing classes that can be mixed and matched [57]. Class
structures that are narrow and deep represent trees of classes that are related by a common
ancestor [58]. There are advantages and disadvantages to each approach. Forests of classes are
more loosely coupled, but they may not exploit all the commonality that exists. Trees of classes
exploit this commonality, so that individual classes are smaller than in forests. However, to
understand a particular class, it is usually necessary to understand the meaning of all the classes
it inherits from or uses. The proper shape of a class structure is highly problem-dependent. We
must make similar trade-offs among inheritance, aggregation, and dependency relationships. For
example, should the class Car inherit, contain, or use the classes named Engine and Wheel? In
this case, we suggest that an aggregation relationship is more appropriate than an inheritance
relationship. Meyer states that between the classes A and B, “inheritance is appropriate if every
instance of B may also be viewed as an instance of A. The client relationship is appropriate when
every instance of B simply possesses one or more attributes of A” [59]. From another
perspective, if the behavior of an object is more than the sum of its individual parts, creating an
aggregation relationship rather than an inheritance relationship between the appropriate classes is
probably superior.

80
Mechanisms and Visibility
Deciding on the relationship among objects is mainly a matter of designing the mechanisms
whereby these objects interact. The question the developer must ask is simply this: Where does
certain knowledge go? For example, in a manufacturing plant, materials (called lots) enter
manufacturing cells to be processed. As they enter certain cells, we must notify the room’s
manager to take appropriate action. We now have a design choice: Is the entry of a lot into a
room an operation on the room, an operation on the lot, or an operation on both? If we decide
that it is an operation on the room, the room must be visible to the lot. If we decide that it is an
operation on the lot, the lot must be visible to the room because the lot must know what room it
is in. Lastly, if we consider this to be an operation on both the room and the lot, we must arrange
for mutual visibility. We must also decide on some visibility relationship between the room and
the manager (and not the lot and the manager); either the manager must know the room it
manages, or the room must know of its manager.
Choosing Implementations
Only after we stabilize the outside view of a given class or object do we turn to its inside view.
This perspective involves two different decisions: a choice of representation for a class or object
and the placement of the class or object in a module.
Representation
The representation of a class or object should almost always be one of the encapsulated secrets of
the abstraction. This makes it possible to change the representation (e.g., to alter the time and
space semantics) without violating any of the functional assumptions that clients may have made.
As Wirth wisely states, “The choice of representation is often a fairly difficult one, and it is not
uniquely determined by the facilities available. It must always be taken in light of the operations
that are to be performed upon the data” [60]. For example, given a class whose objects denote a
set of flight-plan information, do we optimize the representation for fast searching or for fast
insertion and deletion? We cannot optimize for both, so our choice must be based on the
expected use of these objects. Sometimes it is not easy to choose, and we end up with families of
classes whose interfaces are virtually identical but whose implementations are radically different,
in order to provide different time and space behavior.
One of the more difficult trade-offs when selecting the implementation of a class is between
computing the value of an object’s state versus storing it as a field. For example, suppose we
have the class Cone, which includes the method Volume. Invoking this method returns the
volume of the object. As part of the representation of this class, we are likely to use fields for the
height of the cone and the radius of its base. Should we have an additional field in which we
store the volume of the object, or should the method Volume just calculate it every time [61]? If
we want this method to be fast, we should store the volume as a field. If space efficiency is more
important to us, we should calculate the value. Which representation is better depends entirely on
the particular problem. In any case, we should be able to choose an implementation
independently of the class’s outside view; indeed, we should even be able to change this
representation without its clients caring.

81
Packaging
Similar issues apply to the declaration of classes and objects within modules. The competing
requirements of visibility and information hiding usually guide our design decisions about where
to declare classes and objects. Generally, we seek to build functionally cohesive, loosely coupled
modules. Many nontechnical factors influence these decisions, such as matters of reuse, security,
and documentation. Like the design of classes and objects, module design is not to be taken
lightly. As Parnas, Clements, and Weiss note with regard to information hiding, “Applying this
principle is not always easy. It attempts to minimize the expected cost of software over its period
of use and requires that the designer estimate the likelihood of changes. Such estimates are based
on past experience and usually require knowledge of the application area as well as an
understanding of hardware and software technology” [63].
OBJECT-ORIENTED ANALYSIS
The boundaries between analysis and design are fuzzy, although the focus of each is quite
distinct. In analysis, the focus is to fully analyze the problem at hand and to model the world by
discovering the classes and objects that form the vocabulary of the problem domain. In design,
we invent the abstractions and mechanisms in our models that provide the design of the solution
to be built. In the following sections, we examine a number of proven approaches for analysis
that are relevant to object-oriented systems.
Classical Approaches
A number of methodologists have proposed various sources of classes and objects, derived from
the requirements of the problem domain. We call these approaches classical because they derive
primarily from the principles of classical categorization. For example, Shlaer and Mellor suggest
that candidate classes and objects usually come from one of the following sources [32]:
■ Tangible things Cars, telemetry data, pressure sensors
■ Roles Mother, teacher, politician
■ Events Landing, interrupt, request
■ Interactions Loan, meeting, intersection
From the perspective of database modeling, Ross offers a similar list [33]:
■ People Humans who carry out some function
■ Places Areas set aside for people or things
■ Things Physical objects, or groups of objects, that are tangible
■ Organizations Formally organized collections of people, resources, facilities, and capabilities
having a defined mission,whose existence is largely independent of individuals

82
■ Concepts Principles or ideas not tangible per se; used to organize or keep track of business
activities and/or communications
■ Events Things that happen, usually to something else at a given date and time, or as steps in an
ordered sequence
Coad and Yourdon suggest yet another set of sources of potential objects [34]:
■ Structure “Is a” and “part of” relationships
■ Other systems External systems with which the application interacts
■ Devices Devices with which the application interacts
■ Events remembered A historical event that must be recorded
■ Roles played The different roles users play in interacting with the application
■ Locations Physical locations, offices, and sites important to the application
■ Organizational units Groups to which users belong
At a higher level of abstraction, Coad introduces the idea of subject areas, which are basically
logical groups of classes that relate to some higher-level system function.
Behavior Analysis
Whereas these classical approaches focus on tangible things in the problem domain, another
school of thought in object-oriented analysis focuses on dynamic behavior as the primary source
of classes and objects.1 These approaches are
1. Shlaer and Mellor extended their earlier work to focus on behavior as well. In particular, they
studied the lifecycle of each object as a means of understanding the boundaries [35]. more akin
to conceptual clustering: We form classes based on groups of objects that exhibit similar
behavior. Wirfs-Brock, Wilkerson, and Wiener, for example, emphasize responsibilities, which
denote “the knowledge an object maintains and the actions an object can perform.
Responsibilities are meant to convey a sense of the purpose of an object and its place in the
system. The responsibilities of an object are all the services it provides for all of the contracts it
supports” [36]. In this manner, we group things that have common responsibilities, and we form
hierarchies of classes involving superclasses that embody general responsibilities and subclasses
that specialize their behavior.
Rubin and Goldberg offer an approach to identifying classes and objects derived from system
functions. As they suggest, “the approach we use emphasizes first understanding what takes
place in the system. These are the system behaviors. We next assign these behaviors to parts of
the system, and try to understand who initiates and who participates in these behaviors. . . .
Initiators and participants that play significant roles are recognized as objects, and are assigned
the behavioral responsibilities for these roles” [37].

83
Rubin’s concept of system behavior is closely related to the idea of function points, first
suggested in 1979 by Albrech. A function point is “defined as one end-user business function”
[38]. A business function represents some kind of output, inquiry, input, file, or interface.
Although the information-system roots of this definition show through, the idea of a function
point generalizes to all kinds of automated systems: A function point is any relevant outwardly
visible and testable behavior of the system.
Domain Analysis
The principles we have discussed thus far are typically applied to the development of single,
specific applications. Domain analysis, on the other hand, seeks to identify the classes and
objects that are common to all applications within a given domain, such as patient record
tracking, bond trading, compilers, or missile avionics systems. If you are in the midst of a design
and stuck for ideas as to the key abstractions that exist, a narrow domain analysis can help by
pointing you to the key abstractions that have proven useful in other related systems. Domain
analysis works well because, except for special situations, there are very few truly unique kinds
of software systems.
The idea of domain analysis was first suggested by Neighbors. We define domain analysis as “an
attempt to identify the objects, operations, and relationships [that] domain experts perceive to be
important about the domain” [39]. Moore and Bailin suggest the following steps in domain
analysis.
■ Construct a strawman generic model of the domain by consulting with domain experts.
■ Examine existing systems within the domain and represent this understanding in a common
format.
■ Identify similarities and differences between the systems by consulting with domain experts.
■ Refine the generic model to accommodate existing systems. Domain analysis may be applied
across similar applications (vertical domain analysis), as well as to related parts of the same
application (horizontal domain analysis). For example, when starting to design a new patient-
monitoring system, it is reasonable to survey the architecture of existing systems to understand
what key abstractions and mechanisms were previously employed and to evaluate which were
useful and which were not. Similarly, an accounting system must provide many different kinds
of reports. By considering these reports within the same application as a single domain, a domain
analysis can lead the developer to an understanding of the key abstractions and mechanisms that
serve all the different kinds of reports. The resulting classes and objects reflect a set of key
abstractions and mechanisms generalized to the immediate report generation problem; therefore,
the resulting design is likely to be simpler than if each report had been analyzed and designed
separately.
Who exactly is a domain expert? Often, a domain expert is simply a user, such as a train engineer
or dispatcher in a railway system, or a nurse or doctor in a hospital. A domain expert typically
will not be a software developer; more commonly, he or she is simply a person who is intimately
familiar with all the elements of a particular problem. A domain expert speaks the vocabulary of
the problem domain.

84
Some managers may be concerned with the idea of direct communication between developers
and end users (for some, even more frightening is the prospect of letting an end user see a
developer!). For highly complex systems, domain analysis may involve a formal process, using
the resources of multiple domain experts and developers over a period of many months. Such a
formal analysis is not necessary on all projects, particularly smaller projects. Often, all it takes to
clear up a design problem is a brief meeting between a domain expert and an architect or
developer. It is truly amazing to see what a little bit of domain knowledge can do to enable
intelligent design decisions. Indeed, we find it highly useful to have many such meetings
throughout the design of a system. Domain analysis is rarely a monolithic activity; it is better
focused if we consciously choose to analyze a little and then design a little.
Use Case Analysis
In isolation, the practices of classical analysis, behavior analysis, and domain analysis all depend
on a large measure of personal experience on the part of the analyst. For the majority of
development projects, this is unacceptable because such a process is neither deterministic nor
predictably successful. However, there is one practice that can be coupled with all three of these
earlier approaches, to drive the process of analysis in a meaningful way. That practice is use case
analysis, first formalized by Jacobson. Jacobson et al. define a use case as “A behaviourally
related sequence of transactions performed by an actor in a dialogue with the system to provide
some measurable value to the actor” [41].
Briefly, we can apply use case analysis as early as requirements analysis, at which time end
users, other domain experts, and the development team enumerate the scenarios that are
fundamental to the system’s operation. (We need not elaborate on these scenarios at first; we can
simply enumerate them.) These scenarios collectively describe the system functions of the
application. Analysis then proceeds by a study of each scenario, possibly using storyboarding
techniques similar to practices in the television and movie industry [42]. As the team walks
through each scenario, they must identify the objects that participate in the scenario, the
responsibilities of each object, and the ways those objects collaborate with other objects, in terms
of the operations each invokes on the other. In this manner, the team is forced to craft a clear
separation of concerns among all abstractions. As the development process continues, these
initial scenarios are expanded to consider exceptional conditions as well as secondary system
behaviors. The results from these secondary scenarios introduce new abstractions or add, modify,
or reassign the responsibilities of existing abstractions. Scenarios also serve as the basis of
system tests.
CRC Cards
CRC cards emerged as a simple yet marvelously effective way to analyze scenarios.2 First
proposed by Beck and Cunningham as a tool for teaching objectoriented programming [44],
CRC cards have proven to be a useful development tool that facilitates brainstorming and
enhances communication among developers. A CRC card is nothing more than a 3�5 index
card,3 on which the analyst writes—in pencil—the name of a class (at the top of the card), its
responsibilities (on one half of the card), and its collaborators (on the other half of the card). One
card is created for each class identified as relevant to the scenario. As the team members walk
through the scenario, they may assign new responsibilities to an existing class, group certain

85
responsibilities to form a new class, or (most commonly) divide the responsibilities of one class
into more fine-grained ones and perhaps distribute these responsibilities to a different class.
CRC cards can be spatially arranged to represent patterns of collaboration. As viewed from the
dynamic semantics of the scenario, the cards are arranged to show the flow of messages among
prototypical instances of each class; as viewed from the static semantics of the scenario, the
cards are arranged to represent generalization/ specialization or aggregation hierarchies among
the classes.
Informal English Description
A radical alternative to classical object-oriented analysis was first proposed by Abbott, who
suggests writing an English description of the problem (or a part of a problem) and then
underlining the nouns and verbs [45]. The nouns represent candidate objects, and the verbs
represent candidate operations on them. Abbott’s approach is useful because it is simple and
because it forces the developer to work in the vocabulary of the problem space. However, it is by
no means a rigorous approach, and it definitely does not scale well to anything beyond fairly
trivial problems. Human language is a terribly imprecise vehicle of expression, so the quality of
the resulting list of objects and operations depends on the writing skill of its author. Furthermore,
any noun can be verbed, and any verb can be nouned; therefore, it is easy to skew the candidate
list to emphasize either objects or operations.
Structured Analysis
Some organizations have tried to use the products of structured analysis as a front end to object-
oriented design. This technique appears appealing only because a large number of analysts are
skilled in structured analysis, and computer-aided software engineering (CASE) tools exist that
support the automation of these methods. Personally, we discourage the use of structured
analysis as a front end to object-oriented design.
This approach starts with an essential model of the system, as described by data flow diagrams
and the other products of structured analysis. These diagrams provide a reasonably formal model
of the problem. From this model, we may proceed to identify the meaningful classes and objects
in our problem domain in three different ways. McMenamin and Palmer suggest starting with an
analysis of the data dictionary and proceeding to analyze the model’s context diagram. As they
state, “With your list of essential data elements, think about what they tell you or what they
describe. If they were adjectives in a sentence, for instance, what nouns would they modify? The
answers to this question make up the list of candidate objects” [47]. These candidate objects
typically derive from the surrounding environment, from the essential inputs and outputs, and
from the products, services, and other resources managed by the system.
The next two techniques involve analyzing individual data flow diagrams. Given a particular
data flow diagram (using the terminology of Ward and Mellor [48]), candidate objects may be
derived from the following:
■ External entities
■ Data stores

86
■ Control stores
■ Control transformations
Candidate classes derive from two sources:
■ Data flows
■ Control flows
This leaves us with data transformations, which we assign either as operations on existing
objects or as the behavior of an object we invent to serve as the agent responsible for this
transformation. Seidewitz and Stark suggest another technique, which they call abstraction
analysis. Abstraction analysis focuses on the identification of central entities, which are similar
in nature to central transforms in structured design. As they state, “In structured analysis, input
and output data are examined and followed inwards until they reach the highest level of
abstraction. The processes between the inputs and the outputs form the central transform. In
abstraction analysis a designer does the same, but also examines the central transform to
determine which processes and states represent the best abstract model of what the system does”
[49]. After identifying the central entity in a particular data flow diagram, abstraction analysis
proceeds to identify all the supporting entities by following the afferent and efferent data flows
from the central entity and grouping the processes and states encountered along the way. In
practice, Seidewitz and Stark have found abstraction analysis a difficult technique to apply
successfully, and as an alternative they recommend object-oriented analysis methods [50].
We must strongly emphasize that structured design, as normally coupled with structured
analysis, is entirely orthogonal to the principles of object-oriented design. Our experience
indicates that using structured analysis as a front end to object-oriented design often fails when
the developer is unable to resist the urge to fall back into the abyss of the structured design
mindset. Another very real danger is the fact that many analysts tend to write data flow diagrams
that reflect a design rather than an essential model of the problem. It is tremendously difficult to
build an object-oriented system from a model that is so obviously biased toward algorithmic
decomposition. This is why we prefer object-oriented analysis as the front end to object-oriented
design: There is simply less danger of polluting the design with preconceived algorithmic
notions. If you must use structured analysis as a front end, for whatever honorable reasons, 4 we
suggest that you stop writing data flow diagrams as soon as they start to smell of a design instead
of an essential model. Also, it is a healthy practice to walk away from the products of structured
analysis once the design is fully under way. Remember that the products of development,
including data flow diagrams, are not ends in themselves; they should be viewed simply as tools
along the way that aid the developer’s intellectual comprehension of the problem and its
implementation.
One typically writes a data flow diagram and then invents the mechanisms that implement the
desired behavior. Practically speaking, the very act of design changes the developer’s
understanding of the problem. Thus, only the products of structured analysis that are at a
sufficiently high level of abstraction should be retained. They capture an essential model of the
problem and so lend themselves to any number of different designs.

87
KEY ABSTRACTIONS AND MECHANISMS
A key abstraction is a class or object that forms part of the vocabulary of the problem domain.
The primary value of identifying such abstractions is that they give boundaries to our problem;
they highlight the things that are in the system and therefore relevant to our design, and they
suppress the things that are outside the system and therefore superfluous.
In the previous chapter, we used the term mechanism to describe any structure whereby objects
collaborate to provide some behavior that satisfies a requirement of the problem. Whereas the
design of a class embodies the knowledge of how individual objects behave, a mechanism is a
design decision about how collections of objects cooperate. Mechanisms thus represent patterns
of behavior. Let us now discuss the identification and refinement of these key abstractions and
mechanisms.
Identifying Key Abstractions
The identification of key abstractions is highly domain-specific. As Goldberg states, the
“appropriate choice of objects depends, of course, on the purposes to which the application will
be put and the granularity of information to be manipulated” [51].
As we mentioned earlier, the identification of key abstractions involves two processes: discovery
and invention. Through discovery, we come to recognize the abstractions used by domain
experts; if the domain expert talks about it, the abstraction is usually important [52]. Through
invention, we create new classes and objects that are not necessarily part of the problem domain
but are useful artifacts in the design or implementation. For example, a customer using an
automated teller speaks in terms of accounts, deposits, and withdrawals; these words are part of
the vocabulary of the problem domain. A developer of such a system uses these same
abstractions but must also introduce new ones, such as databases, screen managers, lists, queues,
and so on. These key abstractions are artifacts of the particular design, not of the problem
domain.
Refining Key Abstractions
Once we identify a certain key abstraction as a candidate, we must evaluate it according to the
metrics described in the previous chapter. As Stroustrup suggests, “Often this means that the
programmer must focus on the questions: how are objects of this class created? Can objects of
this class be copied and/or destroyed? What operations can be done on such objects? If there are
no good answers to such questions, the concept probably wasn’t ‘clean’ in the first place, and it
might be a good idea to think a bit more about the problem and the proposed solution instead of
immediately starting to ‘code around’ the problems” [53]. Given a new abstraction, we must
place it in the context of the existing class and object hierarchies we have designed. Practically
speaking, this is neither a topdown nor a bottom-up activity. As Halbert and O’Brien observe,
“You do not always design types in a type hierarchy by starting with a supertype and then
creating the subtypes. Frequently, you create several seemingly disparate types, realize they are
related, and then factor out their common characteristics into one or more supertypes several
passes up and down are usually required to produce a complete and correct program design”
[54]. This is not a license to hack, but an observation, based on experience, that object-oriented

88
design is both incremental and iterative. Stroustrup makes a similar observation when he notes
that “the most common reorganizations of a class hierarchy are factoring the common part of two
classes into a new class and splitting a class into two new ones” [55].
Placing classes and objects at the right levels of abstraction is difficult. Sometimes we may find a
general subclass and so may choose to move it up in the class structure, thus increasing the
degree of sharing. This is called class promotion [56]. Similarly, we may find a class to be too
general, thus making inheritance by a subclass difficult because of the large semantic gap. This is
called a grainsize conflict [57]. In either case, we strive to identify cohesive and loosely coupled
abstractions, so as to mitigate these two situations.
Naming Key Abstractions
Naming things properly—so that they reflect their semantics—is often treated lightly by most
developers yet is important in capturing the essence of the abstractions we are describing.
Software should be written as carefully as English prose, with consideration given to the reader
as well as to the computer [58]. Consider for a moment all the names we may need just to
identify a single object: We have the name of the object itself, the name of its class, and the
name of the module in which that class is declared. Multiply this by thousands of objects and
possibly hundreds of classes, and you have a very real problem. We offer the following
suggestions.
■ Objects should be named with proper noun phrases, such as theSensor or just simply shape.
■ Classes should be named with common noun phrases, such as Sensor or Shape.
■ The names chosen should reflect the names used and recognized by the domain experts,
whenever possible.
■ Modifier operations should be named
with active verb phrases, such as draw
or moveLeft.
■ Selector operations should imply a
query or be named with verbs of the
form “to be,” such as extentOf or
isOpen.
■ The use of underscores and styles of
capitalization are largely matters of
personal taste. No matter which
cosmetic style you use, at least have
your programs be self-consistent.
Identifying Mechanisms
Consider a system requirement for an
automobile: Pushing the accelerator should cause the engine to run faster, and releasing the

89
accelerator should cause the engine to
run slower. How this actually comes
about is absolutely immaterial to the
driver. Any mechanism may be
employed as long as it delivers the
required behavior, and thus which
mechanism is selected is largely a
matter of design choice. More
specifically, any of the following
designs might be considered.
■ A mechanical linkage connects the
accelerator directly to the fuel injectors.
■ An electronic mechanism connects a
pressure sensor below the accelerator to a computer that controls the fuel injectors (a drive-by-
wire mechanism).
■ No linkage exists. The gas tank is placed on the roof of the car, and gravity causes fuel to flow
to the engine. Its rate of flow is regulated by a clip around the fuel line; pushing on the
accelerator pedal eases tension on the clip, causing the fuel to flow faster (a low-cost
mechanism).
Which mechanism a developer chooses from a set of alternatives is most often a result of other
factors, such as cost, reliability, manufacturability, and safety. Just as it is rude for a client to
violate the interface of another object, so it is socially unacceptable for objects to step outside the
boundaries of the rules of behavior dictated by a particular mechanism. Indeed, it would be
surprising for a driver if stepping on an accelerator turned on the car’s lights instead of causing
the engine to run faster. Whereas key abstractions reflect the vocabulary of the problem domain,
mechanisms are the soul of the design. During the design process, the developer must consider
not only the design of individual classes but also how instances of these classes work together.
Again, the use of scenarios drives this analysis process.
Once a developer decides on a particular pattern of collaboration, the work is distributed among
many objects by defining suitable methods in the appropriate classes. Ultimately, the protocol of
an individual class encompasses all the operations required to implement all the behavior and all
the mechanisms associated with each of its instances.
Mechanisms thus represent strategic design decisions, as does the design of a class structure. In
contrast, however, the interface of an individual class is more of a tactical design decision. These
strategic decisions must be made explicitly; otherwise, we will end up with a mob of relatively
uncooperative objects, all pushing and shoving to do their work with little regard for other
objects. The most elegant, lean, and fast programs embody carefully engineered mechanisms.
Mechanisms as Patterns
Mechanisms are actually one in a spectrum of patterns we find in well-structured software
systems. At the low end of the food chain, we have idioms. An idiom is an expression peculiar to

90
a certain programming language or application culture, representing a generally accepted
convention for use of the language.5 For example, in CLOS, no programmer would use
underscores in function or variable names, although this is common practice in Ada [59]. Part of
the effort in learning a programming language is learning its idioms, which are usually passed
down as folklore from programmer to programmer. However, as Coplien points out, idioms play
an important role in codifying low-level patterns. He notes that “many common programming
tasks [are] idiomatic” and therefore identifying such idioms allows “using C++ constructs to
express functionality outside the language proper, while giving the illusion of being part of the
language” [60]. Whereas idioms are part of a programming culture, at the high end of the food
chain, we have frameworks. A framework is a collection of classes that provides a set of services
for a particular domain; a framework thus exports a number of individual classes and
mechanisms that clients can use or adapt. Frameworks represent reuse in the large. They are
often the product of commercial ventures, such as Microsoft’s .NET Framework, or open source
efforts such as Apache Software Foundation’s Struts framework and the JUnit testing framework
(Erich Gamma and Kent Beck), among many others.
Examples of Mechanisms
Consider the drawing mechanism commonly used in graphical user interfaces. Several objects
must collaborate to present an image to a user: a window, a view, the model being viewed, and
some client that knows when (but not how) to display this model. The client first tells the
window to draw itself. Since it may encompass several subviews, the window next tells each of
its subviews to draw themselves. Each subview in turn tells its model to draw itself, ultimately
resulting in an image shown to the user. In this mechanism, the model is entirely decoupled from
rendering of the window and view in which it is presented. This is the model-view-controller
paradigm (MVC pattern) [61]. A similar mechanism is employed in almost every object-oriented
graphical user interface framework. Mechanisms thus represent a level of reuse that is higher
than the reuse of individual classes.
For example, the MVC paradigm is used extensively in the Smalltalk user interface. The MVC
paradigm in turn builds on another mechanism, the dependency mechanism, which is embodied
in the behavior of the Smalltalk base class Model and thus pervades much of the Smalltalk class
library. Examples of mechanisms and patterns may be found in virtually every domain. For
example, the structure of an operating system may be described at the highest level of abstraction
according to the mechanism used to dispatch programs. In artificial intelligence, a variety of
mechanisms have been explored for the design of reasoning systems. One of the most widely
used paradigms is the blackboard mechanism, in which individual knowledge sources
independently update a blackboard. There is no central control in such a mechanism, but any
change to the blackboard may trigger an agent to explore some new problem-solving path [63].
Coad has similarly identified a number of common mechanisms in objectoriented systems,
including patterns of time association, event logging, and broadcasting [64]. In each case, these
mechanisms manifest themselves not as individual classes but as the structure of collaborating
classes. This completes our study of classification and of the concepts that serve as the
foundation of object-oriented design. The next three chapters focus on notation, process, and
pragmatics.

91
OBJECT ORIENTED DESIGN
The emphasis in programming methods is primarily on the proper and effective use of particular
language mechanisms. By contrast, design methods emphasize the proper and effective
structuring of a complex system. What, then, is objectoriented design (OOD)? We suggest the
following:
Object-oriented design is a method of design encompassing the process of objectoriented
decomposition and a notation for depicting both logical and physical as well as static and
dynamic models of the system under design. There are two important parts to this definition:
object-oriented design (1) leads to an object-oriented decomposition and (2) uses different
notations to express different models of the logical (class and object structure) and physical
(module and process architecture) design of a system, in addition to the static and dynamic
aspects of the system.
The support for object-oriented decomposition is what makes object-oriented design quite
different from structured design: The former uses class and object abstractions to logically
structure systems, and the latter uses algorithmic abstractions. We will use the term object-
oriented design to refer to any method that leads to an object-oriented decomposition. Designing
object-oriented software is hard, and designing reusable object-oriented software is even harder.
You must find pertinent objects, factor them into classes at the right granularity, define class
interfaces and inheritance hierarchies, and establish key relationships among them. Your design
should be specific to the problem at hand but also general enough to address future problems and
requirements. You also want to avoid redesign, or at least minimize it. Experienced object-
oriented designers will tell you that a reusable and flexible design is difficult if not impossible to
get "right" the first time. Before a design is finished, they usually try to reuse it several times,
modifying it each time.
Unlike conventional software design methods, OOD results in a design that achieves a number of
different levels of modularity. Major system components are organized into subsystems, a
system-level “module.” Data and the operations that manipulate the data are encapsulated into
objects—a modular form that is the building block of an OO system. In addition, OOD must
describe the specific data organization of attributes and the procedural detail of each individual
operation.
These represent data and algorithmic pieces of an OO system and are contributors to overall
modularity. The unique nature of object-oriented design lies in its ability to build upon four
important software design concepts: abstraction, information hiding, functional independence,
and modularity (Chapter 13). All design methods strive for software that exhibits these
fundamental characteristics, but only OOD provides a mechanism that enables the designer to
achieve all four without complexity or compromise. Object-oriented design, object-oriented
programming, and object-oriented testing are construction activities for OO systems. In this
chapter, we consider the first step in construction.

92
Design For Object-Oriented Systems
In Chapter 13, we introduced the concept of a design pyramid for conventional software. Four
design layers—data, architectural, interface, and component level—were defined and discussed.
For object-oriented systems, we can also define a design pyramid, but the layers are a bit
different. Referring to Figure 22.1, the four layers of the OO design pyramid are
The subsystem layer contains a representation of each of the subsystems that enable the
software to achieve its customer-defined requirements and to implement the technical
infrastructure that supports customer requirements.
The class and object layer contains the class hierarchies that enable the system to be created
using generalizations and increasingly more targeted specializations. This layer also contains
representations of each object.
The message layer contains the design details that enable each object to communicate with its
collaborators. This layer establishes the external and internal interfaces for the system.
The responsibilities layer contains the data structure and algorithmic design for all attributes
and operations for each object.
The design pyramid focuses exclusively on the design of a specific product or system. It should
be noted, however, that another “layer” of design exists, and this layer forms the foundation on
which the pyramid rests. The foundation layer focuses on the design of domain objects (called
design patterns later in this chapter). Domain objects play a key role in building the

93
infrastructure for the OO system by providing support for human/computer interface activities,
task management, and data management. Domain objects can also be used to flesh out the design
of the application itself.
Conventional vs. OO Approaches
Conventional approaches to software design apply a distinct notation and set of heuristics to map
the analysis model into a design model. Recalling Figure 13.1, each element of the conventional
analysis model maps into one or more layers of the design model. Like conventional software
design, OOD applies data design when attributes are represented, interface design when a
messaging model is developed, and component-level (procedural) design for the design of
operations. It is important to note that the architecture of an OO design has more to do with the
collaborations among objects than with the flow of control between components of the system.
Although similarity between the conventional and OO design models does exist, we have chosen
to rename the layers of the design pyramid to reflect more accurately the nature of an OO design.
Figure 22.2 illustrates the relationship between the OO analysis model (Chapter 21) and design
model that will be derived from it.
The subsystem design is derived by considering overall customer requirements (represented with
use-cases) and the events and states that are externally observable (the object-behavior model).
Class and object design is mapped from the description of attributes, operations, and
collaborations contained in the CRC model. Message design is driven by the object-relationship
model, and responsibilities design is derived using the attributes, operations, and collaborations
described in the CRC model. Fichman and Kemerer [FIC92] suggest ten design modeling

94
components that may be used to compare various conventional and object-oriented design
methods:
1. Representation of hierarchy of modules.
2. Specification of data definitions.
3. Specification of procedural logic.
4. Indication of end-to-end processing sequences.
5. Representation of object states and transitions.
6. Definition of classes and hierarchies.
7. Assignment of operations to classes.
8. Detailed definition of operations.
9. Specification of message connections.
10. Identification of exclusive services.
Because many conventional and object-oriented design approaches are available, it is difficult to
develop a generalized comparison between the two methods. It can be stated, however, that
modeling dimensions 5 through 10 are not supported using structured design (Chapter 14) or its
derivatives.
Design Issues
Bertrand Meyer [MEY90] suggests five criteria for judging a design method's ability to achieve
modularity and relates these to object-oriented design:
• Decomposability—the facility with which a design method helps the designer to decompose a
large problem into subproblems that are easier to solve.
• Composability—the degree to which a design method ensures that program components
(modules), once designed and built, can be reused to create other systems.
• Understandability—the ease with which a program component can be understood without
reference to other information or other modules.
• Continuity—the ability to make small changes in a program and have these changes manifest
themselves with corresponding changes in just one or a very few modules.
• Protection—an architectural characteristic that will reduce the propagation of side effects if an
error does occur in a given module.

95
From these criteria, Meyer [MEY90] suggests five basic design principles that can be derived for
modular architectures: (1) linguistic modular units, (2) few interfaces, (3) small interfaces (weak
coupling), (4) explicit interfaces, and (5) information hiding.
Modules are defined as linguistic modular units when they "correspond to syntactic units in the
language used" [MEY90]. That is, the programming language to be used should be capable of
supporting the modularity defined directly. For example, if the designer creates a subroutine, any
of the older programming languages (e.g., FORTRAN, C, Pascal) could implement it as a
syntactic unit. But if a package that contains data structures and procedures and identifies them
as a single unit were defined, a language such as Ada (or another object-oriented language)
would be necessary to directly represent this type of component in the language syntax.
To achieve low coupling (a design concept introduced in Chapter 13), the number of interfaces
between modules should be minimized ("few interfaces") and the amount of information that
moves across an interface should be minimized ("small interfaces"). Whenever components do
communicate, they should do so in an obvious and direct way ("explicit interfaces"). For
example, if component X and component Y communicate through a global data area (what we
called common coupling in Chapter 13), they violate the principle of explicit interfaces because
the communication between the components is not obvious to an outside observer. Finally, we
achieve the principle of information hiding when all information about a component is hidden
from outside access, unless that information is specifically defined as public information.
The design criteria and principles presented in this section can be applied to any design method
(e.g., we can apply them to structured design). As we will see, however, the object-oriented
design method achieves each of the criteria more efficiently than other approaches and results in
modular architectures that allow us to meet each of the modularity criteria most effectively.
The OOD Landscape
As we noted in Chapter 21, a wide variety of object-oriented analysis and design methods were
proposed and used during the 1980s and 1990s. These methods established the foundation for
modern OOD notation, design heuristics, and models. A brief overview of the most important
early OOD methods follows:
The Booch method. As we noted in Chapter 21, the Booch method [BOO94] encompasses both
a “micro development process” and a “macro development process.” In the design context,
macro development encompasses an architectural planning activity that clusters similar objects
in separate architectural partitions, layers objects by level of abstraction, identifies relevant
scenarios, creates a design prototype, and validates the design prototype by applying it to usage
scenarios. Micro development defines a set of “rules” that govern the use of operations and
attributes and the domain-specific policies for memory management, error handling, and other
infrastructure functions; develops scenarios that describe the semantics of the rules and policies;
creates a prototype for each policy; instruments and refines the prototype; and reviews each
policy so that it “broadcasts its architectural vision” [BOO94].
The Rumbaugh method. The object modeling technique [RUM91] encompasses a design
activity that encourages design to be conducted at two different levels of abstraction. System

96
design focuses on the layout for the components that are needed to construct a complete product
or system. The analysis model is partitioned into subsystems, which are then allocated to
processors and tasks. A strategy for implementing data management is defined and global
resources and the control mechanisms required to access them are identified. Object design
emphasizes the detailed layout of an individual object. Operations are selected from the analysis
model and algorithms are defined for each operation. Data structures that are appropriate for
attributes and algorithms are represented. Classes and class attributes are designed in a manner
that optimizes access to data and improves computational efficiency. A messaging model is
created to implement the object relationships (associations).
The Jacobson method. The design activity for OOSE (object-oriented software engineering)
[JAC92] is a simplified version of the proprietary objector method, also developed by Jacobson.
The design model emphasizes traceability to the OOSE analysis model. First, the idealized
analysis model is adapted to fit the real world environment. Then primary design objects, called
blocks,2 are created and categorized as interface blocks, entity blocks, and control blocks.
Communication between blocks during execution is defined and the blocks are organized into
subsystems.
The Coad and Yourdon method. The Coad and Yourdon method for OOD [COA91] was
developed by studying how “effective object-oriented designers” do their design work. The
design approach addresses not only the application but also the infrastructure for the application
and focuses on the representation of four major system components: the problem domain
component, the human interaction component, the task management component, and the data
management component.
The Wirfs-Brock method. Wirfs-Brock, Wilkerson, and Weiner [WIR90] define a continuum
of technical tasks in which analysis leads seamlessly into design. Protocols3 for each class are
constructed by refining contracts between objects. Each operation (responsibility) and protocol
(interface design) is designed at a level of detail that will guide implementation. Specifications
for each class (defining private responsibilities and detail for operations) and each subsystem
(identifying all encapsulated classes and theinteraction between subsystems) are developed.
Although the terminology and process steps for each of these OOD methods differ, the overall
OOD processes are reasonably consistent. To perform object-oriented design, a software
engineer should perform the following generic steps:
1. Describe each subsystem and allocate it to processors and tasks.
2. Choose a design strategy for implementing data management, interface support, and task
management.
3. Design an appropriate control mechanism for the system.
4. Perform object design by creating a procedural representation for each operation and data
structures for class attributes.
5. Perform message design using collaborations between objects and object relationships.

97
6. Create the messaging model.
7. Review the design model and iterate as required.
It is important to note that the design steps discussed in this section are iterative. That is, they
may be executed incrementally, along with additional OOA activities, until a completed design is
produced.
A Unified Approach to OOD
In Chapter 21, we noted that Grady Booch, James Rumbaugh, and Ivar Jacobson combined the
best features of their individual object-oriented analysis and design methods into a unified
method. The result, called the Unified Modeling Language has become widely used throughout
the industry.4 During analysis modeling (Chapter 21), the user model and structural model views
are represented. These provide insight into the usage scenarios for the system (providing
guidance for behavioral modeling) and establish a foundation for the implementation and
environment model views by identifying and describing the static structural elements of the
system.
UML is organized into two major design activities: system design and object design. The
primary objective of UML system design is to represent the software architecture. Bennett,
McRobb, and Farmer [BEN99] discuss this issue in the following way: In terms of object-
oriented development, the conceptual architecture is concerned with the structure of the static
class model and the connections between components of the model.
The module architecture describes the way the system is divided into subsystems or modules and
how they communicate by exporting and importing data. The code architecture defines how the
program code is organized into files and directories and grouped into libraries. The execution
architecture focuses on the dynamic aspects of the system and the communication between
components as tasks and operations execute. The definition of the “subsystems” noted by
Bennett et al. is a primary concern during UML system design.
UML object design focuses on a description of objects and their interactions with one another. A
detailed specification of attribute data structures and a procedural design of all operations are
created during object design. The visibility5 for all class attributes is defined and interfaces
between objects are elaborated to define the details of a complete messaging model. System and
object design in UML are extended to consider the design of user interfaces, data management
with the system to be built, and task management for the subsystems that have been specified.
User interface design in UML draws on the same concepts and principles discussed in Chapter
15. The user model view drives the user interface design process, providing a scenario that is
elaborated iteratively to become a set of interface classes.

98
Data management design establishes a set of classes and collaborations that allow the system
(product) to manage persistent data (e.g., files and databases). Task management design
establishes the infrastructure that organizes subsystems into tasks and then manages task
concurrency. The process flow for design is illustrated in Figure 22.3.7
Throughout the UML design process, the user model view and structure model view are
elaborated into the design representation outlined above. This elaboration activity is discussed in
the sections that follow.
The System Design Process
System design develops the architectural detail required to build a system or product. The system
design process encompasses the following activities:
• Partition the analysis model into subsystems.
• Identify concurrency that is dictated by the problem.
• Allocate subsystems to processors and tasks.
• Develop a design for the user interface.
• Choose a basic strategy for implementing data management.
• Identify global resources and the control mechanisms required to access them.

99
• Design an appropriate control mechanism for the system, including task management.
• Consider how boundary conditions should be handled.
• Review and consider trade-offs.
In the sections that follow, design activities related to each of these steps are considered in more
detail.
Partitioning the Analysis Model
One of the fundamental analysis principles (Chapter 11) is partitioning. In OO system design, we
partition the analysis model to define cohesive collections of classes, relationships, and behavior.
These design elements are packaged as a subsystem.
In general, all of the elements of a subsystem share some property in common. They all may be
involved in accomplishing the same function; they may reside within the same product hardware,
or they may manage the same class of resources. Subsystems are characterized by their
responsibilities; that is, a subsystem can be identified by the services that it provides [RUM91].
When used in the OO system design context, a service is a collection of operations that perform a
specific function (e.g., managing word-processor files, producing a three-dimensional rendering,
translating an analog video signal into a compressed digital image).
As subsystems are defined (and designed), they should conform to the following design criteria:
• The subsystem should have a well-defined interface through which all communication with the
rest of the system occurs.
• With the exception of a small number of “communication classes,” the classes within a
subsystem should collaborate only with other classes within the subsystem.
• The number of subsystems should be kept low.
• A subsystem can be partitioned internally to help reduce complexity.
When two subsystems communicate with one another, they can establish a client/server link or a
peer-to-peer link [RUM91]. In a client/server link, each of the subsystems takes on one of the
roles implied by client and server. Service flows from server to client in only one direction. In a
peer-to-peer link, services may flow in either direction.
When a system is partitioned into subsystems, another design activity, called layering, also
occurs. Each layer [BUS96] of an OO system contains one or more subsystems and represents a
different level of abstraction of the functionality required to accomplish system functions. In
most cases, the levels of abstraction are determined by the degree to which the processing
associated with a subsystem is visible to an end-user.
For example, a four-layer architecture might might include (1) a presentation layer (the
subsystems associated with the user interface), (2) an application layer (the subsystems that

100
perform the processing associated with the application), (3) a data formatting layer (the
subsystems that prepare the data for processing), and (4) a database layer (the subsystems
associated with data management). Each layer moves deeper into the system, representing
increasingly more environment-specific processing. Buschmann and his colleagues [BUS96]
suggest the following design approach for layering:
1. Establish layering criteria. That is, decide how subsystems will be grouped in a layered
architecture.
2. Determine the number of layers. Too many introduce unnecessary complexity; too few may
harm functional independence.
3. Name the layers and allocate subsystems (with their encapsulated classes) to a layer. Be
certain that communication between subsystems (classes) on one layer and other subsystems
(classes) at another layer follow the design philosophy for the architecture.
4. Design interfaces for each layer.
5. Refine the subsystems to establish the class structure for each layer.
6. Define the messaging model for communication between layers.
7. Review the layer design to ensure that coupling between layers is minimized (a client/server
protocol can help accomplish this).
8. Iterate to refine the layered design.
Concurrency and Subsystem Allocation
The dynamic aspect of the object-behavior model provides an indication of concurrency among
classes (or subsystems). If classes (or subsystems) are not active at the same time, there is no
need for concurrent processing. This means that the classes (or subsystems) can be implemented
on the same processor hardware. On the other hand, if classes (or subsystems) must act on events
asynchronously and at the same time, they are viewed as concurrent. When subsystems are
concurrent, two allocation options exist: (1) Allocate each subsystem to an independent
processor or (2) allocate the subsystems to the same processor and provide concurrency support
through operating system features.
Concurrent tasks are defined [RUM91] by examining the state diagram for each object. If the
flow of events and transitions indicates that only a single object is active at any one time, a
thread of control has been established. The thread of control continues even when one object
sends a message to another object, as long as the first object waits for a response. If, however,
the first object continues processing after sending a message, the thread of control splits.
Tasks in an OO system are designed by isolating threads of control. For example, while the
SafeHome security system is monitoring its sensors, it can also be dialing the central monitoring
station for verification of connection. Since the objects involved in both of these behaviors are

101
active at the same time, each represents a separate thread of control and each can be defined as a
separate task.
If the monitoring and dialing activities occur sequentially, a single task could be implemented.
To determine which of the processor allocation options is appropriate, the designer must consider
performance requirements, costs, and the overhead imposed by interprocessor communication.
The Task Management Component
Coad and Yourdon [COA91] suggest the following strategy for the design of the objects that
manage concurrent tasks:
• The characteristics of the task are determined.
• A coordinator task and associated objects are defined.
• The coordinator and other tasks are integrated.
The characteristics of a task are determined by understanding how the task is initiated. Event-
driven and clock-driven tasks are the most commonly encountered. Both are activated by an
interrupt, but the former receives an interrupt from some outside source (e.g., another processor,
a sensor) while that latter is governed by a system clock.
In addition to the manner in which a task is initiated, the priority and criticality of the task must
also be determined. High-priority tasks must have immediate access to system resources. High-
criticality tasks must continue to operate even if resource availability is reduced or the system is
operating in a degraded state. Once the characteristics of the task have been determined, object
attributes and operations required to achieve coordination and communication with other tasks
are defined. The basic task template (for a task object) takes the form [COA91]
Task name—the name of the object
Description—a narrative describing the purpose of the object
Priority—task priority (e.g., low, medium, high)
Services—a list of operations that are responsibilities of the object
Coordinates by—the manner in which object behavior is invoked
Communicates via—input and output data values relevant to the task
This template description can then be translated into the standard design model (incorporating
representation of attributes and operations) for the task object(s).
The User Interface Component
Although the user interface component is implemented within the context of the problem
domain, the interface itself represents a critically important subsystem for most modern

102
applications. The OO analysis model (Chapter 21) contains usage scenarios (called use-cases)
and a description of the roles that users play (called actors) as they interact with the system.
These serve as input to the user interface design process.
Once the actor and its usage scenario are defined, a command hierarchy is identified. The
command hierarchy defines major system menu categories (the menu bar or tool palette) and all
subfunctions that are available within the context of a major system menu category (the menu
windows). The command hierarchy is refined iteratively until every use-case can be
implemented by navigating the hierarchy of functions. Because a wide variety of user interface
development environments already exist, the design of GUI elements is not necessary. Reusable
classes (with appropriate attributes and operations) already exist for windows, icons, mouse
operations, and a wide variety of other interaction functions. The implementer need only
instantiate objects that have appropriate characteristics for the problem domain.
The Data Management Component
Data management encompasses two distinct areas of concern: (1) the management of data that
are critical to the application itself and (2) the creation of an infrastructure for storage and
retrieval of objects. In general, data management is designed in a layered fashion. The idea is to
isolate the low-level requirements for manipulating data structures from the higher-level
requirements for handling system attributes. Within the system context, a database management
system is often used as a common data store for all subsystems. The objects required to
manipulate the database are members of reusable classes that are identified using domain
analysis (Chapter 21) or are supplied directly by the database vendor. A detailed discussion of
database design for OO systems is beyond the scope of this book.9
The design of the data management component includes the design of the attributes and
operations required to manage objects. The relevant attributes are appended to every object in the
problem domain and provide information that answers the question, “How do I store myself?”
Coad and Yourdon [COA91] suggest the creation of an object-server class “with services to (a)
tell each object to save itself and (b) retrieve stored objects for use by other design components.”
As an example of data management for the sensor object discussed as part of the SafeHome
security system, the design could specify a flat file called “sensor.” Each record would
correspond to a named instance of sensor and would contain the values of each sensor attribute
for that named instance. Operations within the object server class would enable a specific object
to be stored and retrieved when it is needed by the system. For more complex objects, it might be
necessary to specify a relational database or an object-oriented database to accomplish the same
function.
The Resource Management Component
A variety of different resources are available to an OO system or product; and in many instances,
subsystems compete for these resources at the same time. Global system resources can be
external entities (e.g., a disk drive, processor, or communication line) or abstractions (e.g., a
database, an object). Regardless of the nature of the resource, the software engineer should
design a control mechanism for it. Rumbaugh and his colleagues [RUM91] suggest that each

103
resource should be owned by a “guardian object.” The guardian object is the gatekeeper for the
resource, controlling access to it and moderating conflicting requests for it.
Intersubsystem Communication
Once each subsystem has been specified, it is necessary to define the collaborations that exist
between the subsystems. The model that we use for object-to-object collaboration can be
extended to subsystems as a whole. Figure 22.4 illustrates a collaboration model. As we noted
earlier in this chapter, communication can occur by establishing a client/server link or a peer-to-
peer link. Referring to the figure, we must specify the contract that exists between subsystems.
Recall that a contract provides an indication of the ways in which one subsystem can interact
with another. The following design steps can be applied to specify a contract for a subsystem
[WIR90]:
1. List each request that can be made by collaborators of the subsystem. Organize the
requests by subsystem and define them within one or more appropriate contracts. Be sure
to note contracts that are inherited from superclasses.
2. For each contract, note the operations (both inherited and private)that are required to
implement the responsibilities implied by the contract. Be sure to associate the
operations with specific classes that reside within a subsystem.

104
3. Considering one contract at a time, create a table of the form shown in Figure 22.5. For
each contract, the following entries are made in the table:
Type—the type of contract (i.e., client/server or peer-to-peer).
Collaborators—the names of the subsystems that are parties to the contract.
Class—the names of the classes (contained within a subsystem) that support services implied by
the contract.
Operation—the names of the operations (within the class) that implement the services.
Message format—the message format required to implement the interaction between
collaborators. Draft an appropriate message description for each interaction between the
subsystems.
4. If the modes of
interaction between
subsystems are complex, a
subsystem- collaboration
diagram, illustrated in
Figure 22.6 is created. The
collaboration graph is
similar in form to the event
flow diagram discussed in
Chapter 21. Each subsystem
is represented along with its
interactions with other
subsystems. The contracts
that are invoked during an
interaction are noted as shown. The details of the interaction are determined by looking up the
contract in the subsystem collaboration table (Figure 22.5)

105
The Object Design Process
Borrowing from a metaphor that was introduced earlier in this book, the OO system design might
be viewed as the floor plan of a house. The floor plan specifies the purpose of each room and the
architectural features that connect the rooms to one another and to the outside environment. It is
now time to provide the details that are required to build each room. In the context of OOD,
object design focuses on the “rooms.”
Bennett and his colleagues [BEN99] discuss object design in the following way: Object design is
concerned with the detailed design of the objects and their interactions. It is completed within the
overall architecture defined during system design and according to agreed design guidelines and
protocols. Object design is particularly concerned with the specification of attribute types, how
operations function, and how objects are linked to other objects. It is at this stage that the basic
concepts and principles associated with component level design (Chapter 16) come into play.
Local data structures are defined (for attributes) and algorithms (for operations) are designed.
Object Descriptions
A design description of an object (an instance of a class or subclass) can take one of two forms
[GOL83]: (1) a protocol description that establishes the interface of an object by defining each
message that the object can receive and the related operation that the object performs when it
receives the message or (2) an implementation description that shows implementation details for
each operation implied by a message that is passed to an object. Implementation details include
information about the object's private part; that is, internal details about the data structures that
describe the object’s attributes and procedural details that describe operations.
The protocol description is nothing more than a set of messages and a corresponding comment
for each message. For example, a portion of the protocol description for the object motion
sensor (described earlier) might be MESSAGE (motion.sensor) --> read: RETURNS sensor.ID,
sensor.status; This describes the message required to read the sensor. Similarly, MESSAGE
(motion.sensor) --> set: SENDS sensor.ID, sensor.status; sets or resets the status of the sensor.
For a large system with many messages, it is often possible to create message categories.
For example, message categories for the SafeHome system object might include system
configuration messages, monitoring messages, event messages, and so forth. An implementation
description of an object provides the internal ("hidden") details that are required for
implementation but are not necessary for invocation. That is, the designer of the object must
provide an implementation description and must therefore create the internal details of the object.
However, another designer or implementer who uses the object or other instances of the object
requires only the protocol description but not the implementation description.
An implementation description is composed of the following information: (1) a specification of
the object's name and reference to class; (2) a specification of private data structure with
indication of data items and types; (3) a procedural description of each operation or,
alternatively, pointers to such procedural descriptions. The implementation description must
contain sufficient information to provide for proper handling of all messages described in the
protocol description.

106
Cox [COX85] characterizes the difference between the information contained in the protocol
description and that contained in the implementation description in terms of "users" and
"suppliers" of services. A user of the service provided by an object must be familiar with the
protocol for invoking the service; that is, for specifying what is desired. The supplier of the
service (the object itself) must be concerned with how the service is to be supplied to the user;
that is, with implementation details.
Designing Algorithms and Data Structures
A variety of representations contained in the analysis model and the system design provide a
specification for all operations and attributes. Algorithms and data structures are designed using
an approach that differs little from the data design and component-level design approaches
discussed for conventional software engineering. An algorithm is created to implement the
specification for each operation. In many cases, the algorithm is a simple computational or
procedural sequence that can be implemented as a self-contained software module. However, if
the specification of the operation is complex, it may be necessary to modularize the operation.
Conventional component-level design techniques can be used to accomplish this. Data structures
are designed concurrently with algorithms. Since operations invariably manipulate the attributes
of a class, the design of the data structures that best reflect the attributes will have a strong
bearing on the algorithmic design of the corresponding operations.
Although many different types of operations exist, they can generally be divided into three broad
categories: (1) operations that manipulate data in some way (e.g., adding, deleting, reformatting,
selecting), (2) operations that perform a computation, and (3) operations that monitor an object
for the occurrence of a controlling event.
For example, the SafeHome processing narrative contains the sentence fragments: "sensor is
assigned a number and type" and "a master password is programmed for arming and disarming
the system." These two phrases indicate a number of things: • That an assign operation is
relevant for the sensor object.
• That a program operation will be applied to the system object.
• That arm and disarm are operations that apply to system (also that system status may
ultimately be defined (using data dictionary notation) as system status = [armed | disarmed]
The operation program is allocated during OOA, but during object design it will be refined into a
number of more specific operations that are required to configure the system. For example, after
discussions with product engineering, the analyst, and possibly the marketing department, the
designer might elaborate the original processing narrative and write the following for program
(potential operations—verbs— are underlined):
Program enables the SafeHome user to configure the system once it has been installed. The user
can (1) install phone numbers; (2) define delay times for alarms; (3) build a sensor table that
contains each sensor ID, its type, and location; and (4) load a master password.
Therefore, the designer has refined the single operation program and replaced it with the
operations: install, define, build, and load. Each of these new operations becomes part of the

107
system object, has knowledge of the internal data structures that implement the object's
attributes, and is invoked by sending the object messages of the form MESSAGE (system) -->
install: SENDS telephone.number; This implies that, to provide the system with an emergency
phone number, an install message will be sent to system.
Verbs connote actions or occurrences. In the context of object design formalization, we consider
not only verbs but also descriptive verb phrases and predicates (e.g., "is equal to") as potential
operations. The grammatical parse is applied recursively until each operation has been refined to
its most-detailed level. Once the basic object model is created, optimization should occur.
Rumbaugh and his colleagues [RUM91] suggest three major thrusts for OOD design
optimization:
• Review the object-relationship model to ensure that the implemented design leads to efficient
utilization of resources and ease of implementation. Add redundancy where necessary.
• Revise attribute data structures and corresponding operation algorithms to enhance efficient
processing.
• Create new attributes to save derived information, thereby avoiding recomputation.
A detailed discussion of OO design optimization is beyond the scope of this book.
The interested reader should refer to [RUM91] and [CHA93]. For a discussion of how these
concepts translate into the UML process, the reader should examine [JAC99] and [RUM99].
Program Components and Interfaces
An important aspect of software design quality is modularity; that is, the specification of
program components (modules) that are combined to form a complete program. The object-
oriented approach defines the object as a program component that is itself linked to other
components (e.g., private data, operations). But defining objects and operations is not enough.
During design, we must also identify the interfaces between objects and the overall structure
(considered in an architectural sense) of the objects. Although a program component is a design
abstraction, it should be represented in the context of the programming language used for
implementation. To accommodate OOD, the programming language to be used for
implementation should be capable of creating the following program component (modeled after
Ada):
PACKAGE program-component-name IS
TYPE specification of data objects
•
•
PROC specification of related operations . . .

108
PRIVATE
data structure details for objects
PACKAGE BODY program-component-name IS
PROC operation.1 (interface description) IS
•
•
END
PROC operation.n (interface description) IS
•
•
•
END
END program-component-name
Referring to the Ada-like PDL (program design language) just shown, a program component is
specified by indicating both data objects and operations. The specification part of the component
indicates all data objects (declared with the TYPE statement) and the operations (PROC for
procedure) that act on them. The private part (PRIVATE) of the component provides otherwise
hidden details of data structure and processing. In the context of our earlier discussion, the
PACKAGE is conceptually similar to objects discussed throughout this chapter.
The first program component to be identified should be the highest-level module from which all
processing originates and all data structures evolve. Referring once again to the SafeHome
example, we can define the highest-level program component as PROCEDURE SafeHome
software
The SafeHome software component can be coupled with a preliminary design for the following
packages (objects):
PACKAGE system IS
TYPE system data
PROC install, define, build, load
PROC display, reset, query, modify, call

109
PRIVATE
PACKAGE BODY system IS
PRIVATE
system.id IS STRING LENGTH (8);
verification phone.number, telephone.number, ...
IS STRING LENGTH (8);
sensor.table DEFINED
sensor.type IS STRING LENGTH (2),
sensor.number, alarm.threshold IS NUMERIC;
PROC install RECEIVES (telephone.number)
{design detail for operation install}
•••
END system
PACKAGE sensor IS
TYPE sensor data
PROC read, set, test
PRIVATE
PACKAGE BODY sensor IS
PRIVATE
sensor.id IS STRING LENGTH (8);
sensor.status IS STRING LENGTH (8);
alarm.characteristics DEFINED
threshold, signal type, signal level IS NUMERIC,
hardware.interface DEFINED
type, a/d.characteristics, timing.data IS NUMERIC,

110
END sensor
•••
END SafeHome software
Data objects and corresponding operations are specified for each of the program components for
SafeHome software. The final step in the object design process completes all information
required to fully implement data structure and types contained in the PRIVATE portion of the
package and all procedural detail contained in the PACKAGE BODY.
To illustrate the detail design of a program component, we reconsider the sensor package
described earlier. The data structures for sensor attributes have already been defined. Therefore,
the first step is to define the interfaces for each of the operations attached to sensor:
PROC read (sensor.id, sensor.status: OUT);
PROC set (alarm.characteristics, hardware.interface: IN)
PROC test (sensor.id, sensor.status, alarm.characteristics: OUT);
The next step requires stepwise refinement of each operation associated with the sensor package.
To illustrate the refinement, we develop a processing narrative (an informal strategy) for read:
When the sensor object receives a read message, the read process is invoked. The process
determines the interface and signal type, polls the sensor interface, converts A/D characteristics
into an internal signal level, and compares the internal signal level to a threshold value. If the
threshold is exceeded, the sensor status is set to "event." Otherwise, the sensor status is set to "no
event." If an error is sensed while polling the sensor, the sensor status is set to "error." Given the
processing narrative, a PDL description of the read process can be developed:
PROC read (sensor.id, sensor.status: OUT);
raw.signal IS BIT STRING
IF (hardware.interface.type = "s" & alarm.characteristics.signal.type = "B"
THEN
GET (sensor, exception: sensor.status := error) raw.signal;
CONVERT raw.signal TO internal.signal.level;
IF internal.signal.level > threshold
THEN sensor.status := "event";
ELSE sensor.status := "no event";
ENDIF

111
ELSE {processing for other types of s interfaces would be specified}
ENDIF
RETURN sensor.id, sensor.status;
END read
The PDL representation of the read operation can be translated into the appropriate
implementation language. The functions GET and CONVERT are assumed to be available
as part of a run-time library.
Design Patterns
The best designers in any field have an uncanny ability to see patterns that characterize a
problem and corresponding patterns that can be combined to create a solution. Gamma and his
colleagues [GAM95] discuss this when they state: [Y]ou’ll find recurring patterns of classes and
communicating objects in many objectoriented systems. These patterns solve specific design
problems and make object-oriented design more flexible, elegant, and ultimately reusable. They
help designers reuse successful designs by basing new designs on prior experience. A designer
who is familiar with such patterns can apply them immediately to design problems without
having to rediscover them.
Throughout the OOD process, a software engineer should look for every opportunity to reuse
existing design patterns (when they meet the needs of the design) rather than creating new ones.
Describing a Design Pattern
Mature engineering disciplines make use of thousands of design patterns. For example, a
mechanical engineer uses a two-step, keyed shaft as a design pattern. Inherent in the pattern are
attributes (the diameters of the shaft, the dimensions of the keyway, etc.) and operations (e.g.,
shaft rotation, shaft connection). An electrical engineer uses an integrated circuit (an extremely
complex design pattern) to solve a specific element of a new problem. All design patterns can be
described by specifying the following information [GAM95]:
• the name of the pattern
• the intent of the pattern
• the “design forces” that motivate the pattern
• the solution that mitigates these forces
• the classes that are required to implement the solution
• the responsibilities and collaboration among solution classes

112
• guidance that leads to effective implementation
• example source code or source code templates
• cross-references to related design patterns
The design pattern name is itself an abstraction that conveys significant meaning once the
applicability and intent are understood. Design forces describe the data, functional, or behavioral
requirements associated with part of the software for which the pattern is to be applied. In
addition forces define the constraints that may restrict the manner in which the design is to be
derived. In essence, design forces describe the environment and conditions that must exist to
make the design pattern applicable. The pattern characteristics (classes, responsibilities, and
collaborations) indicate the attributes of the design that may be adjusted to enable the pattern to
accommodate a variety of problems. These attributes represent characteristics of the design that
can be searched (e.g., via a database) so that an appropriate pattern can be found. Finally,
guidance associated with the use of a design pattern provides an indication of the ramifications
of design decisions.
The names of objects and subsystems (potential design patterns) should be chosen with care. As
we discuss in Chapter 27, one of the key technical problems in software reuse is simply the
inability to find existing reusable patterns when hundreds or thousands of candidate patterns
exist. The search for the “right” pattern is aided immeasurably by a meaningful pattern name
along with a set of characteristics that help in classifying the object [PRE95].
Using Patterns in Design
In an object-oriented system, design patterns10 can be used by applying two different
mechanisms: inheritance and composition. Inheritance is a fundamental OO concept and was
described in detail in Chapter 20. Using inheritance, an existing design pattern becomes a
template for a new subclass. The attributes and operations that exist in the pattern become part of
the subclass. Composition is a concept that leads to aggregate objects. That is, a problem may
require objects that have complex functionality (in the extreme, a subsystem accomplishes this).
The complex object can be assembled by selecting a set of design patterns and composing the
appropriate object (or subsystem). Each design pattern is treated as a black box, and
communication among the patterns occurs only via welldefined interfaces.
Gamma and his colleagues [GAM95] suggest that object composition should be favored over
inheritance when both options exist. Rather than creating large and sometimes unmanageable
class hierarchies (the consequence of the overuse of inheritance), composition favors small class
hierarchies and objects that remain focused on one objective. Composition uses existing design
patterns (reusable components) in an unaltered form.

113
IDENTIFYING DESIGN ELEMENTS
Purpose：
To analyze interactions of analysis classes to identify design model elements analysis
classes represent conceptual things which can perform behavior.
 Identify Classes, Active Classes and Subsystems
 Identify Subsystem Interfaces
 Identify and Specify Events
 Identify and Specify Signals
In design, analysis classes evolve into a number of different kinds of design elements:
 classes, to represent a set of rather fine-grained responsibilities;
 subsystems, to represent a set of coarse-grained responsibilities, perhaps composed of a
further set of subsystems, but ultimately a set of classes;
 active classes, to represent threads of control in the system;
 interfaces, to represent abstract declarations of responsibilities provided by a class or
subsystem.
In addition, in design we shall also identify:
 events, which are specifications of interesting occurrences in time and space that usually
(if they are noteworthy) require some response from the system; and
 signals, to represent asynchronous mechanisms used to communicate certain types of
events within the system.
Events and the Signals that are used to communicate them, allow us to describe the asynchronous
triggers of behavior to which the system must respond.
Packages versus Subsystems
Subsystems
 Provide behavior
 Completely encapsulate their
contents

114
 Are easily replaced
Packages
 Don’t provide behavior
 Don’t completely encapsulate their contents
 May not be easily replaced
Subsystem Example
Identifying Subsystmes

115
Example: Design Subsystems and Interfaces
Modeling Convention: Subsystems and Interfaces

116
Façade in subsystem
 For subsystems, the most common pattern of access is Facade, a GoF design pattern.
 a public facade object defines the services for the subsystem, and clients
collaborate with the facade, not internal subsystemcomponents
 The Facade pattern is commonly used for "downward" collaboration from a higher to a
lower layer, or for access to services in another subsystem of the same layer.
 The facade should not normally expose many low-level operations.
 Rather, to expose a small number of high-level operations—the coarse-grained
services.
 A facade does not normally do its own work.
 Rather, it is consolidator or mediator to the underlying subsystem objects, which
do the work.
Session Facades and the Application Layer

117
DETAILED DESIGN
After high-level design…
-level design is done, you have
structure of your software system
-level details of each module in your system, including
can use to meet its responsibilities
-functional requirements that might impact the module
Detailed Design
-level design, a designer’s focus shifts to low-level design
as precisely as possible
specified
-wide invariants can be specified
suggested
Danger, Will Robinson!
over specify a design
design using a programming
language
perhaps unnecessarily constraining the
approaches a developer would use to accomplish the same job
text to specify a module’s detailed
design
PDL: Process Design
Language

118
detailed design
be used as a detailed design language
to indicate the behavior of an object at a
high level
On the Web…
the “process design language” that Jalote
describes
similar called “program design
language”
in that document (which is slightly different than
what appears in our textbook)
book Code Complete by Steve McConnell
PDL constructs
with natural language text or other PDL
constructs
IF construct
IF condition THEN
statements
ELSE
statements
ENDIF
PDL constructs, continued
CASE construct
CASE variable OF

119
value1: statements
…
valueN: statements
ENDCASE
DO condition
statements
ENDDO
Example
minmax(input)
ARRAY a
DO UNTIL end of input
READ an item into a
ENDDO
max, min := first item of a
DO FOR each item in a
IF max < item THEN set max to item
IF min > item THEN set min to item
ENDDO
END
Verification
tools may be able to perform consistency
analysis on design specifications
diagram defined as methods on the
objects shown in the sequence diagram
high-level design

120
process of a software development
project
Metrics
Cyclomatic Complexity
larger number of decision
statements is likely more complex
module plus 1
cyclomatic complexity of a module should
be less than 10
ighly correlated to the size of a module and has been found to be correlated to
the number of faults found in a module
Data Bindings
between modules in a software system
module p and q have a shared variable x
connection between p and q
Cohesion Metric (1 of 3)
module are being used by the code of that
module

121
e graph
variable: Ri = set of nodes that reference
the ith variable of the module
culation continued
independent paths from I to T that pass
through any element of the set S; G is the set of all statements in the module
G, then dim(S) is equivalent to the cyclomatic complexity of the module
statements plus 1 (i.e. the cyclomatic
complexity of that set)
ables is then computed as:
most of the variables will be used by
statements in most of the paths through that module.

Unit ii oo design 9

More Related Content

What's hot (18)

Similar to Unit ii oo design 9 (20)

Recently uploaded (20)

Unit ii oo design 9