Object-Oriented

Analysis and Design

Grady Booch
Robert A. Maksimchuk

CONCEPTS Michael W. Engle

Bobbi J. Young, Ph.D.
CHAPTER
CHAPTER 1:
1: COMPLEXITY
COMPLEXITY Jim Conallen
Kelli A. Houston
 2

Concepts
• In the early days of object technology, many people were initially
introduced to “OO” through programming languages.
• As time passed, languages improved, development techniques
evolved, best practices emerged, and formal object-oriented
methodologies were created.
• And, Today object-oriented development is a rich and powerful
development model.
• This section takes a step back to look at the supporting theory that
supplies the foundation for all of the above and provides insight into
why things work the way they do in the object-oriented paradigm.
 3

Chapter 1: Complexity
• A physician, a civil engineer, and a computer scientist were arguing
about what was the oldest profession in the world. The physician
remarked,
• “Well, in the Bible, it says that God created Eve from a rib (spine)
taken out of Adam. This clearly required surgery, and so I can rightly
claim that mine is the oldest profession in the world.”
• The civil engineer interrupted, and said, “But even earlier in the book
of Genesis, it states that God created the order of the heavens and the
earth from out of the chaos. This was the first and certainly the most
spectacular application of civil engineering.
• Therefore, fair doctor, you are wrong: mine is the oldest profession in
the world.”
• The computer scientist leaned back in her chair, smiled, and then said
confidently, “Ah, but who do you think created the chaos?”
• Thus computer professionals are one who are responsible to create
chaos (disorder, confusion).
 4

Complexity

• Chaos can be referred to the complex system.

• As it is difficult to understand chaos,
so is the complex systems.

• “The more complex the system, the more open it is to total

breakdown”.

• Rarely would a builder think about adding a new sub-basement to an

existing 100-story building.
• Doing that would be very costly and would undoubtedly invite failure.

• But looking to the other side. (i.e. computer professionals)

• Amazingly, users of software systems rarely think twice about asking
for equivalent changes.
• Besides, they argue, it is only a simple matter of programming.
 5

The Structure of Complex Systems

• The Structure of a Personal Computer
 A personal computer is a device of moderate complexity. Most are
composed of the same major elements: a central processing unit (CPU),
a monitor, a keyboard, and some sort of secondary storage device,
usually either a CD or DVD drive and hard disk drive.
• The Structure of Plants and Animals
 Plants consist of three major structures (roots, stems, and leaves). Each
of these has a different, specific structure. For example, roots encompass
branch roots, root hairs, the root apex, and the root cap. Similarly, a
cross-section of a leaf reveals its epidermis, mesophyll, and vascular
tissue. Each of these structures is further composed of a collection of
cells, and inside each cell we find yet another level of complexity,
encompassing such elements as chloroplasts, a nucleus, and so on.
• The Structure of Matter
 The study of fields as diverse as astronomy and nuclear physics provides
us with many other examples of incredibly complex systems.
 Astronomers study galaxies that are arranged in clusters. Stars, planets,
and debris are the constituents of galaxies.
 6

The Inherent Complexity of Software

• A dying star on the verge of collapse (when converting to black hole), a
child learning how to read, white blood cells rushing to attack a virus:

• These are but a few of the objects in the physical world that involve
truly awesome complexity.

• Software may also involve elements of great complexity; however, the

complexity we find here is of a fundamentally different kind.
 7

Defining Software Complexity

• We do realize that some software systems are not complex.
• These are the largely forgettable applications (which we can forget
after creating it), that are specified, constructed, maintained, and used
by the same person, usually the amateur (inexpert) programmer or
the professional developer working in isolation.
• Such systems tend to have a very limited purpose and a very short life
span.
• We can afford to throw them away and replace them with entirely new
software rather than attempt to reuse them, repair them, or extend
their functionality.
• Such applications are generally more tedious than difficult to develop;
consequently, learning how to design them does not interest us.

• Instead, we are much more interested in the challenges of developing

what we will call industrial-strength software.
 8

Defining Software Complexity

• Industrial-Strength Software:
• Applications that exhibit a very rich set of behaviors.
• Applications that maintain the integrity of hundreds of thousands of
records of information while allowing concurrent updates and
queries. Example: railway reservation system.
• And systems for the command and control of real-world entities, such
as the routing of air or railway traffic.
• Software systems such as these tend to have a long life span, and over
time, many users come to depend on their proper functioning.
• In the world of industrial-strength software, we also find domain-
specific applications, and programs that mimic (copy) some aspect of
human intelligence.
• Such applications (Artificial Intelligence, Neural Networks, etc.) are
generally products of research and development, they are no less
complex, as they are the means of incremental and exploratory
development (i.e. used to explore something).
 9

Why Software Is Inherently Complex

• As Brooks suggests, “The complexity of software is an essential
property, not an accidental one”.

• We observe that this inherent complexity derives from four elements:

• the complexity of the problem domain,

• the difficulty of managing the development process,

• the flexibility possible through software,

• and the problems of characterizing the behavior of discrete systems.

 10

The Complexity of the Problem Domain

• Consider the requirements for the electronic system of a multiengine
aircraft, a cellular phone switching system, or an autonomous robot.
• The raw functionality of such systems is difficult enough to understand,
but now add all of the nonfunctional requirements such as usability,
performance, cost, survivability, and reliability.
• This uncontrolled external complexity is what causes the random
complexity.
• This external complexity usually is generated from the “communication
gap” that exists between the users of a system and its developers:
• Users generally find it very hard to give precise expression to their
needs in a form that developers can understand.
• This is not so much the fault of either the users or the developers of a
system; rather, it occurs because each group generally lacks expertise in
the domain of the other.
• Also, users and developers have different perspectives on the nature of
the problem and make different assumptions regarding the nature of
the solution.
 11

The Difficulty of Managing the Development Process

 12

The Difficulty of Managing the Development Process

• The fundamental task of the software development team is to engineer the

illusion of simplicity—to shield users from this vast and often random
external complexity.
• Certainly, size is no great virtue in a software system. We strive to write less
code by inventing clever and powerful mechanisms that give us this illusion
of simplicity, as well as by reusing frameworks of existing designs and code.
• Today, it is not unusual to find delivered systems whose size is measured in
hundreds of thousands or even millions of lines of code. (Like any Operating
System with millions of lines of code).
• No one person can ever understand such a system completely.
• Even if we decompose our implementation in meaningful ways, we still end
up with hundreds and sometimes thousands of separate modules.
• This amount of work demands that we use a team of developers, and ideally
we use as small a team as possible.
• However, no matter what its size, there are always significant challenges
associated with team development.
• Having more developers means more complex communication and hence
more difficult coordination.
 13

The Flexibility Possible through Software

• A home-building company generally does not operate its own tree
farm from which to harvest trees for lumber;
• It is highly unusual for a construction firm to build an onsite steel mill
to forge custom girders for a new building.

• But, in software industry such practice is common.

• Software offers the ultimate flexibility, so it is possible for a developer
to express almost any kind of abstraction or idea.
• This flexibility turns out to be an incredibly seductive (hard to resist,
attractive) property, however, because it also forces the developer to
craft virtually all the primitive (basic) building blocks upon which
these higher-level abstractions stand.
• While the construction industry has uniform building codes and
standards for the quality of raw materials, few such standards exist in
the software industry.
 14

The Problems of Characterizing the Behavior of Discrete Systems

• If we toss a ball into the air, we can reliably predict its path because
we know that under normal conditions, certain laws of physics apply.
• It never happens that in halfway through its flight it suddenly stopped
and shot straight up into the air.

• Within a large application, there may be hundreds or even thousands

of variables as well as more than one thread of control. The entire
collection of these variables, their current values, and the current
address and calling stack of each process within the system constitute
the present state of the application.

• Because we execute our software on digital computers, we have a

system with discrete states.
• By contrast, analog systems such as the motion of the tossed ball are
continuous systems.
 15

The Problems of Characterizing the Behavior of Discrete Systems

• Parnas suggests, “when we say that a system is described by a

continuous function, we are saying that it can contain no hidden
surprises. Small changes in inputs will always cause correspondingly
small changes in outputs”.

• On the other hand, discrete systems by their very nature have a finite
number of possible states; in large systems, there is a combinatorial
explosion that makes this number very large.
• Each event external to a software system has the potential of placing
that system in a new state, and furthermore, the mapping from state
to state is not always deterministic (away from prediction).

• In the worst circumstances, an external event may corrupt the state of

a system because its designers failed to take into account certain
interactions among events.
 16

Five Attributes of a Complex System

• Considering the nature of this complexity, we conclude that there are
five attributes common to all complex systems.

• Hierarchic Structure
• Relative Primitives
• Separation of Concerns
• Common Patterns
• Stable Intermediate Forms
 17

Hierarchic Structure
• Frequently, complexity takes the form of a hierarchy, whereby a
complex system is composed of interrelated subsystems that have in
turn their own subsystems, and so on, until some lowest level of
elementary components is reached.
• It is important to realize that the architecture of a complex system is a
function of its components as well as the hierarchic relationships
among these components. As Rechtin observes, "All systems have
subsystems and all systems are parts of larger systems.

System

Subsystem Subsystem
1 2

Subsystem Subsystem Subsystem

1.1 1.2 2.1
 18

Relative Primitives
• Regarding the nature of the primitive (simple or basic) (belonging to
an early stage of technical development;) components of a complex
system, our experience suggests that:

• “The choice of what components in a system are primitive is relatively

arbitrary (random) (based on or subject to individual discretion or
preference) and is largely up to the preference (freedom to act or
judge on one's own) of the observer of the system”.

• What is primitive for one observer may be at a much higher level of

abstraction or thought for another.
 19

Separation of Concerns
• Simon calls hierarchic systems decomposable because they can be
divided into identifiable parts; he calls them nearly decomposable
because their parts are not completely independent. This leads us to
another attribute common to all complex systems:
• Intra-component linkages are generally stronger than inter-
component linkages.
• This difference between intra- and inter-component interactions
provides a clear separation of concerns among the various parts of a
system, making it possible to study each part in relative isolation.

In the hierarchy shown right System

SS 1.1, SS 1.2, and SS2.1 are inter-component
for SS 1 and SS 2
whereas SS 1.1 and 1.2 are intra-component Subsystem Subsystem
for SS 1. 1 2

Subsystem Subsystem Subsystem

1.1 1.2 2.1
 20

Common Patterns
• Hierarchic systems are usually composed of only a few different kinds
of subsystems in various combinations and arrangements.
• In other words, complex systems have common patterns.
• These patterns may involve the reuse of small components, such as
the cells found in both plants and animals, or of larger structures,
such as vascular systems, also found in both plants and animals.

System
System

Subsystem Subsystem
1 2

Subsystem Subsystem Subsystem

1.1
1.1 1.2
1.2 2.1
2.1

Com 1 Com 2 Com 3 Com 1 Com 2 Com 1 Com 3 Com 4

 21

Stable Intermediate Forms

• Specifically, “complex systems will evolve from simple systems much
more rapidly if there are stable intermediate forms than if there are
not”.
• A complex system that works is invariably found to have evolved from
a simple system that worked. . . .
• A complex system designed from scratch never works and cannot be
patched up to make it work. You have to start over, beginning with a
working simple system.
• Example can be development of the whole Office System starting from
first developing Notepad or Word pad.
 22

Organized and Disorganized Complexity

• The discovery of common concepts and mechanisms greatly facilitates
our understanding of complex systems.
• For example, with just a few minutes of orientation, an experienced
pilot can step into a multiengine jet aircraft he or she has never flown
before and safely fly the vehicle.

• Having recognized the properties common to all such aircraft, such as

the functioning of the rudder, ailerons, and throttle, the pilot
primarily needs to learn what properties are unique to that particular
aircraft.
• If the pilot already knows how to fly a given aircraft, it is far easier to
learn how to fly a similar one.
 23

The Canonical Form of a Complex System

• Most interesting systems do not embody a single hierarchy; instead, we
find that many different hierarchies are usually present within the same
complex system.
• For example, an aircraft may be studied by decomposing it into its
propulsion system, flight-control system, and so on.
• This decomposition represents a structural, or “part of” hierarchy.
• Alternately, we can cut across the system in an entirely orthogonal way.
• The second hierarchy represents an “is a” hierarchy.
• For example, a turbofan engine is a specific kind of jet engine, and a
Pratt and Whitney TF30 is a specific kind of turbofan engine. Stated
another way, a jet engine represents a generalization of the properties
common to every kind of jet engine; a turbofan engine is simply a
specialized kind of jet engine, with properties that distinguish it, for
example, from ramjet engines.
• In our experience, we have found it essential to view a system from both
perspectives, studying its “is a” hierarchy as well as its “part of”
hierarchy.
 26

The Limitations of the Human Capacity for Dealing with Complexity

• If we know what the design of complex software systems should be

like, then why do we still have serious problems in successfully
developing them?
• As we first begin to analyze a complex software system, we find many
parts that must interact in a assembly of complicated ways, with little
noticeable unity among either the parts or their interactions; this is an
example of disorganized complexity.
• As we work to bring organization to this complexity through the
process of design, we must think about many things at once.
• For example, in an air traffic control system, we must deal with the
state of many different aircraft at once, involving such properties as
their location, speed, and heading.
• Especially in the case of discrete systems, we must cope with a fairly
large, intricate, and sometimes nondeterministic state space.
• Unfortunately, it is absolutely impossible for a single person to keep
track of all of these details at once.
 27

The Limitations of the Human Capacity for Dealing with Complexity

• Experiments by psychologists, such as those of Miller, suggest that the

maximum number of chunks of information that an individual can
simultaneously comprehend is on the order of seven, plus or minus
two.
• This channel capacity seems to be related to the capacity of short-term
memory. Simon additionally notes that processing speed is a limiting
factor:
• It takes the mind about five seconds to accept a new chunk of
information.
• We are thus faced with a fundamental dilemma.
• The complexity of the software systems we are asked to develop is
increasing, yet there are basic limits on our ability to cope with this
complexity.
• How then do we resolve this predicament?
 28

Bringing Order to Chaos

• Certainly, there will always be geniuses among us, people of
extraordinary skill who can do the work of a handful of mere mortal
developers, the software engineering equivalents of Frank Lloyd
Wright or Leonardo da Vinci.
• These are the people whom we seek to deploy as our system architects:
the ones who devise innovative idioms, mechanisms, and frameworks
that others can use as the architectural foundations of other
applications or systems.
• However, “The world is only sparsely populated with geniuses. There
is no reason to believe that the software engineering community has
an inordinately large proportion of them” .
• Although there is a touch of genius in all of us, in the realm of
industrial-strength software we cannot always rely on divine
inspiration to carry us through.
• Therefore, we must consider more disciplined ways to master
complexity.
 29

The Role of Decomposition

• “The technique of mastering complexity has been known since ancient
times: divide et impera (divide and rule)”.
• When designing a complex software system, it is essential to
decompose it into smaller and smaller parts, each of which we may
then refine independently. In this manner, we satisfy the very real
constraint that exists on the channel capacity of human cognition:
• To understand any given level of a system, we need only follow a few
parts (rather than all parts) at once.
 30

Algorithmic Decomposition
• Most of us have been formally trained in the view of top-down
structured design, and so we approach decomposition as a simple
matter of algorithmic decomposition, wherein each module in the
system denotes a major step in some overall process.
• Figure 1–3 is an example of one of the products of structured design, a
structure chart that shows the relationships among various functional
elements of the solution. This particular structure chart illustrates art
of the design of a program that updates the content of a master file. It
was automatically generated from a data flow diagram by an expert
system tool that embodies the rules of structured design
 31

Object-Oriented Decomposition
• In Figure 1–4, we have decomposed the system according to the key
abstractions in the problem domain. Rather than decomposing the
problem into steps such as Get formatted update and Add checksum,
we have identified objects such as Master File and Checksum, which
derive directly from the vocabulary of the problem domain.
 32

Object-Oriented Decomposition
• Although both designs solve the same problem, they do so in quite
different ways.
• In this second decomposition, we view the world as a set of
autonomous agents that collaborate to perform some higher-level
behavior.
• Get Formatted Update thus does not exist as an independent
algorithm; rather, it is an operation associated with the object File of
Updates. Calling this operation creates another object, Update to
Card.
• In this manner, each object in our solution embodies its own unique
behavior, and each one models some object in the real world. From
this perspective, an object is simply a tangible entity that exhibits
some well-defined behavior.
• Because our decomposition is based on objects and not algorithms, we
call this an object-oriented decomposition.
 33

Algorithmic versus Object-Oriented Decomposition

• Which is the right way to decompose a complex system - by

algorithms or by objects?
• Actually, this is a trick question, because the right answer is that both
views are important: the algorithmic view highlights the ordering of
events, and the object-oriented view emphasizes the agents that either
cause action or are the subjects upon which these operations act.
• However, the fact remains that we cannot construct a complex system
in both ways simultaneously, for they are completely orthogonal
(statistically unrelated) views.
• We must start decomposing a system either by algorithms or by
objects, and then use the resulting structure as the framework for
expressing the other perspective.
 35

The Role of Abstraction

• An individual can comprehend only about seven, plus or minus two,
chunks of information at one time.
• This number appears to be independent of information content.
• The span of total judgment and the span of immediate memory
impose severe limitations on the amount of information that we are
able to receive, process and remember.
• By organizing the stimulus input simultaneously into several
dimensions and successively into a sequence of chunks, we manage to
break . . . this informational bottleneck”.
• In contemporary terms, we call this process chunking or abstraction.
• “We (humans) have developed an exceptionally powerful technique
for dealing with complexity. We abstract from it.
• Unable to master the entirety of a complex object, we choose to ignore
its inessential details, dealing instead with the generalized, idealized
model of the object”
 36

The Role of Abstraction

• For example, when studying how photosynthesis works in a plant, we
can focus on the chemical reactions in certain cells in a leaf and ignore
all other parts, such as the roots and stems.
• We are still constrained by the number of things that we can
comprehend at one time, but through abstraction, we use chunks of
information with increasingly greater semantic content.
• This is especially true if we take an object-oriented view of the world
because objects, as abstractions of entities in the real world, represent
a particularly dense and cohesive clustering of information.
 37

The Role of Hierarchy

• Another way to increase the semantic content of individual chunks of
information is by explicitly recognizing the class and object
hierarchies within a complex software system.
• The object structure is important because it illustrates how different
objects collaborate with one another through patterns of interaction
that we call mechanisms.
• The class structure is equally important because it highlights common
structure and behavior within a system.
• Thus, rather than study each individual photosynthesizing cell within
a specific plant leaf, it is enough to study one such cell because we
expect that all others will exhibit similar behavior.
• Although we treat each instance of a particular kind of object as
distinct, we may assume that it shares the same behavior as all other
instances of that same kind of object.
 38

The Role of Hierarchy

• By classifying objects into groups of related abstractions (e.g., kinds of
plant cells versus animal cells), we come to explicitly distinguish the
common and distinct properties of different objects, which further
helps us to master their inherent complexity.
• Identifying the hierarchies within a complex software system is often
not easy because it requires the discovery of patterns among many
objects, each of which may embody some tremendously complicated
behavior.
• Once we have exposed these hierarchies, however, the structure of a
complex system, and in turn our understanding of it, becomes vastly
simplified.
 39

On Designing Complex Systems

• The practice of every engineering discipline—be it civil, mechanical,
chemical, electrical, or software engineering—involves elements of
both science and art.
• “The conception of a design for a new structure can involve as much a
leap of the imagination and as much a synthesis of experience and
knowledge as any artist is required to bring to his canvas or paper.
And once that design is articulated by the engineer as artist, it must be
analyzed by the engineer as scientist in as rigorous an application of
the scientific method as any scientist must make”
 40

Engineering as a Science and an Art

• The role of the engineer as artist is particularly challenging when the
task is to design an entirely new system.
• Especially in the case of reactive systems and systems for command
and control, we are frequently asked to write software for an entirely
unique set of requirements, often to be executed on a configuration of
target processors constructed specifically for this system.
• In other cases, such as the creation of frameworks, tools for research
in artificial intelligence, or information management systems, we may
have a well-defined, stable target environment, but our requirements
may stress the software technology in one or more dimensions.
 41

Engineering as a Science and an Art

• For example, we may be asked to craft systems that are faster, have
greater capacity, or have radically improved functionality. In all these
situations, we try to use proven abstractions and mechanisms as a
foundation on which to build new complex systems.
• In the presence of a large library of reusable software components, the
software engineer must assemble these parts in innovative ways to
satisfy the stated and implicit requirements, just as the painter or the
musician must push the limits of his or her medium.
 42

The Meaning of Design

• In every engineering discipline, design encompasses the disciplined
approach we use to invent a solution for some problem, thus
providing a path from requirements to implementation. In the context
of software engineering,
• Mostow suggests that the purpose of design is to construct a system
that:
• ■ Satisfies a given (perhaps informal) functional specification
• ■ Conforms to limitations of the target medium
• ■ Meets implicit or explicit requirements on performance and
resource usage
• ■ Satisfies implicit or explicit design criteria on the form of the artifact
• ■ Satisfies restrictions on the design process itself, such as its length
or cost, or the tools available for doing the design.
 43

The Meaning of Design

• As Stroustrup suggests, “the purpose of design is to create a clean and
relatively simple internal structure, sometimes also called an
architecture. . . . A design is the end product of the design process” .
• Design involves balancing a set of competing requirements.
• The products of design are models that enable us to reason about our
structures, make trade-offs when requirements conflict, and in
general, provide a blueprint for implementation.
 44

The Importance of Model Building

• The building of models has a broad acceptance among all engineering
disciplines, largely because model building appeals to the principles of
decomposition, abstraction, and hierarchy.
• Each model within a design describes a specific aspect of the system
under consideration.
• As much as possible, we seek to build new models upon old models in
which we already have confidence.
• Models give us the opportunity to fail under controlled conditions. We
evaluate each model in both expected and unusual situations, and
then we alter them when they fail to behave as we expect or desire.
• We have found that in order to express all the sensitivities of a
complex system, we must use more than one kind of model.
• For example, when designing a personal computer, an electrical
engineer must take into consideration the component-level view of the
system as well as the physical layout of the circuit boards.
 45

The Importance of Model Building

• This component view forms a logical picture of the design of the
system, which helps the engineer to reason about the cooperative
behavior of the components.
• The board layout represents the physical packaging of these
components, constrained by the board size, available power, and the
kinds of components that exist.
• From this view, the engineer can independently reason about factors
such as heat dissipation and manufacturability.
• The board designer must also consider dynamic as well as static
aspects of the system under construction.
• Thus, the electrical engineer uses diagrams showing the static
connections among individual components, as well as timing
diagrams that show the behavior of these components over time.
• The engineer can then employ tools such as oscilloscopes and digital
analyzers to validate the correctness of both the static and dynamic
models.
 46

The Elements of Software Design Methodologies

• Clearly, there is no magic, no “silver bullet” that can unfailingly lead the
software engineer down the path from requirements to the implementation of a
complex software system.
• In fact, the design of complex software systems does not lend itself at all to
cookbook approaches.
• Rather, as noted earlier in the fifth attribute of complex systems, the design of
such systems involves an incremental and iterative process.
• Still, sound design methods do bring some much-needed discipline to the
development process.
• The software engineering community has evolved dozens of different design
methodologies.
• Despite their differences, all of these have elements in common. Specifically,
each includes the following:
• ■ Notation The language for expressing each model
• ■ Process The activities leading to the orderly construction of the system’s
models
• ■ Tools The artifacts that eliminate the dullness of model building and enforce
rules about the models themselves, so that errors and inconsistencies can be
exposed.
 47

The Models of Object-Oriented Development

• Is there a “best” design method?

• No, there is no absolute answer to this question, which is actually just
a veiled way of asking the earlier question: What is the best way to
decompose a complex system?
• To say again, we have found great value in building models that are
focused on the “things” we find in the problem space, forming what we
refer to as an object-oriented decomposition.
• Object-oriented analysis and design is the method that leads us to an
object oriented decomposition. By applying object-oriented design, we
create software that is resilient to change and written with economy of
expression.
• We achieve a greater level of confidence in the correctness of our
software through an intelligent separation of its state space.
• Ultimately, we reduce the risks inherent in developing complex
software systems.
 48

Summary
• Software is inherently complex; the complexity of software systems often
exceeds the human intellectual capacity.
• The task of the software development team is to engineer the illusion of
simplicity.
• Complexity often takes the form of a hierarchy; it is useful to model both the “is
a” and the “part of” hierarchies of a complex system.
• Complex systems generally evolve from stable intermediate forms.
• There are fundamental limiting factors of human cognition; we can address
these constraints through the use of decomposition, abstraction, and hierarchy.
• Complex systems can be viewed by focusing on either things or processes; there
are compelling reasons for applying object-oriented decomposition, in which
we view the world as a meaningful collection of objects that collaborate to
achieve some higher-level behavior.
• Object-oriented analysis and design is the method that leads us to an object
oriented decomposition; object-oriented design uses a notation and process for
constructing complex software systems and offers a rich set of models with
which we may reason about different aspects of the system under
consideration.