Object-Oriented

Analysis and Design

Grady Booch

CONCEPTS
Robert A. Maksimchuk
Michael W. Engle
Bobbi J. Young, Ph.D.
CHAPTER
CHAPTER 2:
2: The
The OBJECT
OBJECT MODEL
MODEL
Jim Conallen
Kelli A. Houston
Concepts
• 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.
• 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.
• These differences arise from the fact that structured design methods
build upon structured programming, whereas object-oriented design
builds upon object-oriented programming.
• In this chapter, we will show clearly what object-oriented
development is and what it is not, and how it differs from other
methods through its use of the seven elements of the object model.
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.
• 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 Generations of 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 Generations of Programming Languages

• 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)
▫ Smalltalk 80 Pure object-oriented language
▫ C++ Derived from C and Simula
▫ Ada83 Strong typing; heavy Pascal influence
▫ Eiffel Derived from Ada and Simula
The Generations of Programming Languages

• 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
The Generations of Programming Languages

• 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.
• 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.
• 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.
• Thus, third generation languages such as ALGOL 60 and, later, Pascal
evolved with support for data abstraction.
The Generations of Programming Languages

• The 1970s provided us with a passion 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, 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 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 Generations of Programming Languages

• The Topology of 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).
The Generations of Programming Languages

• The Topology of First- and Early Second-Generation Programming

Languages
• 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.
• An error in one part of a program can have a devastating effect across
the rest of the system because the global data structures are exposed
for all subprograms to see.
• When modifications are made to a large system, it is difficult to
maintain the integrity of the original design.
• Thus threatening the reliability of the entire system and certainly
reducing the overall clarity of the solution.
The Generations of Programming Languages

• 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
• 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 Generations of Programming Languages

• The Topology of Late Second- and Early Third-Generation

Programming Languages
• 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,
showing 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.
• The topology of late second- and early third-generation languages is
largely a variation on the theme of earlier generations.
The Generations of Programming Languages

• 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 need to develop different parts of the same program
independently.
• The answer to this need was the separately compiled module, as Figure
shows.
The Generations of Programming Languages

• The Topology of Late Third-Generation Programming Languages

• 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.
The Generations of Programming Languages

• The Topology of Object-Based and Object- Oriented Programming

Languages

• 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.
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.
• 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.
Foundations of the Object Model
• 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.
Foundations - The Object Model
• As Yonezawa and Tokoro point out,
• “The term ‘object’ emerged almost independently in various fields in
computer science, almost simultaneously in the early 1970s, to refer to
notions that were different in their appearance, yet mutually related.
• All of these ideas were invented to manage the complexity of software
systems in such a way that objects represented components of a
modularly decomposed system or modular units of knowledge
representation”.
Foundations - The Object Model
• Levy adds that the following events have contributed to the evolution
of object-oriented concepts:
▫ Advances in computer architecture, including capability systems
and hardware support for operating systems concepts
▫ Advances in programming languages, as demonstrated in Simula,
Smalltalk, CLU, and Ada
▫ Advances in programming methodology, including modularization
and information hiding

• We would add to this list three more contributions to the foundation

of the object model:
▫ Advances in database models
▫ Research in artificial intelligence
▫ Advances in philosophy and cognitive science
Foundations - The Object Model
• The first person to formally identify the importance of composing
systems in layers of abstraction was Dijkstra. Parnas later introduced
the idea of information hiding, and in the 1970s a number of
researchers, most notably Liskov and Zilles, Guttag, and Shaw [23],
pioneered the development of abstract data type mechanisms. Hoare
contributed to these developments with his proposal for a theory of
types and subclasses.
• Although database technology has evolved somewhat independently
of software engineering, it has also contributed to the object model
[25], primarily through the ideas of the entity-relationship (ER)
approach to data modeling. In the ER model, first proposed by Chen,
the world is modeled in terms of its entities, the attributes of these
entities, and the relationships among these entities.
Object-Oriented Programming
• What, then, is object-oriented programming (OOP)?

• 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.
Object-Oriented Programming
• 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.
Object-Oriented Programming
• 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.
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.
Object-Oriented 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.
Object-Oriented Analysis
• 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.
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”.
• 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”
Elements of the Object Model
• 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.
Elements of the Object Model
• 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
• By major, we mean that a model without any one of these elements is
not object oriented.

• There are three minor elements of the object model:

• 1. Typing 2. Concurrency 3. Persistence
• By minor, we mean that each of these elements is a useful, but not
essential, part of the object model.
The Meaning of Abstraction
• 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”.
• 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.
The Meaning of Abstraction
The Meaning of Abstraction
• “There is a spectrum of abstraction, from objects which closely model
problem domain entities to objects which really have no reason for
existence”.

• 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
• Coincidental abstraction: An object that packages a set of
operations that have no relation to each other
The Meaning of Encapsulation

• 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.
The Meaning of Encapsulation
• 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”.
• Whereas abstraction “helps people to think about what they are
doing,” encapsulation “allows program changes to be reliably made
with limited effort”.
The Meaning of Encapsulation
• 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.
• In both of these cases, objects at one level of abstraction are shielded
from implementation details at lower levels of abstraction.
The Meaning of Encapsulation
• 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.
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”
The Meaning of Modularity
• 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.
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).
The Meaning of Hierarchy
Examples of Hierarchy: 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 inheritance,
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.
• 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.
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.
Applying the Object Model
• 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.
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.
• 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”.
• 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 non object- 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.
Benefits of the Object Model
• 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.
• 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”.
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?
• What are the management implications of using object-oriented
design?
• These issues are the themes of the next few chapters.