ESE Module 5-2
Object-Oriented Analysis
After you’ve had a few days to ponder basic concepts, object-oriented (OO) thinking becomes quite
natural. But OO software engineering can still be a
challenge.
When faced with a problem, how do we characterize it in a way that is amenable to OO software
engineering? What are the relevant objects, attributes, and methods? How do we specify or model a
problem so that we can create an effective design?
Each of these questions is answered within the
context of object-oriented analysis--the first technical
activity that is performed as part of OO software engineering.
OO analysis is grounded in a set of basic principles that were introduced in ESE Module 3-2. We'll
review them briefly in this module:
Readings





1. The information domain of a problem must be represented and understood.
2. Models that depict system information, function and
behavior should be developed.
3. The models (and the problem) must be partitioned in a
manner that uncovers detail in a layered (or hierarchical)
fashion.
4. The analysis process should move from essential information toward implementation detail.
model the information domain
module function
model behavior
partition the models
work from essence to implementation
As we introduce OOA you'll recognize each of these
principles.
OOA is a modeling activity. In this ESE module,
we'll explore the elements of the OOA model and
work to establish a basis for object-oriented design.
Analysis Fundamentals
There is a set of basic principles that transcends the
method that is applied to requirements analysis and
modeling. For this reason, the principles are relevant
to the old school of analysis modeling (structured
analysis) and the new school (OOA).
The following excerpt has been adapted from
Software Engineering: A Practitioner's Approach and
presents basic analysis principles that are applicable
to OOA. (If you have completed Module 3-2, you may
skip this reading.)
Over a period of more than two decades, a number of software analysis and specification methods have been developed. Investigators have identified problems and their
causes and have developed rules and procedures to overcome them. Each analysis method has a unique notation
and point of view. However, all analysis methods are
related by a set of fundamental principles:
By applying these principles, the analyst approaches a
problem systematically. The information domain is examined so that function may be understood more completely.
Models are used so that information can be communicated
in a compact fashion. Partitioning is applied to reduce com
plexity. Essential and implementation views of the software are necessary to accommodate the logical constraints
imposed by processing requirements, and the physical constraints imposed by other system elements.
The Information Domain
All software applications can be collectively called data processing. Interestingly, this term contains a key to our understanding of software requirements. Software is built to
process data, to transform data from one form to another;
that is, to accept input, manipulate it in some way and produce output. This fundamental statement of objective is
true whether we build batch software for a payroll system
or real-time embedded software to control fuel flow to an
automobile engine.
It is important to note, however, that software also
processes events. An event represents some aspect of system control and is really nothing more than boolean data-it is either on or off; true or false; there or not there. For
example, a pressure sensor detects when pressure exceeds
a safe value and sends an alarm signal to monitoring software. The alarm signal is an event that controls the behavior of the system. Therefore, data (numbers, characters,
images, sounds, etc.) and control items (events) both reside
5-2.2 ·· Essential Software Engineering
within the information domain of a problem.
The information domain contains three different views
of the data and control items as each is processed by a computer program: (1) information flow, (2) information content and (3) information structure. To fully understand the
information domain, each of these views should be considered.
Informationflow represents the manner in which data
and control items change as each moves through a system.
Input is transformed to intermediate information, which is
further transformed to output. Along this transformation
path (or paths), additional information may be introduced
from an existing data store (e.g., a disk file or memory
buffer). The transformations that are applied to the data are
functions or subfunctions that a program must perform.
Data and control that move between two transformations
(functions) define the interface for each function.
Information content represents the individual data and
control items that comprise some larger item of information. For example, the data item paycheck is a composite of
a number of important pieces of information: the payee's
name, the net amount to be paid, the gross pay, deductions, and so forth. Therefore, the content of paycheck is
defined by the items that are needed to create it. Similarly,
the content of a control item called system status might be
defined by a string of bits. Each bit represents a separate
item of information that indicates whether a particular
device is on- or off-line.
Information structure represents the internal organization of various data and control items. Are data or control
items to be organized as an n-dimensional table or as a
hierarchical tree structure? Within the context of the structure, what information is related to other information? Is
all information contained within a single structure or are
distinct structures to be used? How does information in
one information structure relate to information in another
structure? These questions and others are answered by an
assessment of information structure. It should be noted
that data stucture, a related concept, refers to the design
and implementation of information structure with software.
or a specialized design language for describing requirements.
Models created during requirements analysis serve a
number of important roles:
Modeling
SafeHome software enables the homeowner to configure the security system when it is installed, monitors all
sensors connected to the security system, and interacts
with the homeowner through a keypad and function keys
contained in the SafeHome control panel.
During installation, the SafeHome control panel is
used to program and configure the system. Each sensor is
assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event
occurs.
When the software senses an event, it rings an audible
alarm attached to the system. After a specified delay time
set by the homeowner during system configuration activities, the software dials the telephone number of a monitoring service and provides information about the location
and the nature of the event that has been detected. The
software will re-dial the number every 20 seconds until
telephone connection is obtained.
All interaction with SafeHome is managed by a user-
We create models to gain a better understanding of the
actual entity to be built. When the entity is a physical thing
(a building, a plane, a machine) we can build a model that
is identical in form and shape, but smaller in scale.
However, when the entity to be built is software, our
model must take a different form. It must be capable of
modeling the information that software transforms, the
functions (and subfunctions) that enable the transformation
to occur, and the behavior of the system as the transformation is taking place.
During software requirements analysis, we create
models of the system to be built. The models focus on what
the system must do, not on how it does it. In many cases,
the models that we create make use of a graphical notation
that depicts information, processing, system behavior, and
other characteristics as distinct and recognizable icons.
Other parts of the model may be purely textual. Descriptive information can be provided using a natural language
 the model aids the analyst in understanding the infermation, function and behavior of a system, thereby making
the requirements analysis task easier and more systematic;
 the model becomes the focal point for review, and
therefore, the key to a determination of completeness, consistency, and accuracy of the specification;
 the model becomes the foundation for design, providing the designer with an essential representation of software that can be mapped into an implementation context.
The analysis methods that are discussed in this ESE
module are actually modeling methods. Although the
modeling method that is used is often a matter of personal
(or organizational) preference, the modeling activity is fundamental to good analysis work.
Partitioning
Problems are often too large and complex to be understood
as a whole. For this reason, we tend to partition (divide)
such problems into parts that can be easily understood,
and establish interfaces between the parts so that overall
function can be accomplished. During requirements analysis, the information, functional, and behavioral domains of
software can be partitioned.
In essence, partitioning decomposes a problem into its
constituent parts. Conceptually, we establish a hierarchical
representation of function or information and then partition the uppermost element by (1) exposing increasing
detail by moving vertically in the hierarchy or (2) functionally decomposing the problem by moving horizontally in
the hierarchy. To illustrate these partitioning approaches,
let us reconsider the SafeHome security system. The software allocation for SafeHome (derived as a consequence of
system engineering and FAST activities) can be stated in
the following paragraph:
Object-Oriented Analysis .. 5-2.3
interaction subsystem that reads input provided through
the keypad and function keys and displays prompting
messages and system status information on the LCD display. Keyboard interaction takes the following form ...
Requirements for SafeHome software may be analyzed by partitioning the information, functional, and
behavioral domains of the product. To illustrate, the functional domain of the problem will be partitioned. Figure 1
illustrates a horizontal decomposition of SafeHome software. The problem is partitioned by representing constituent SafeHome software functions and moving horizontally in the functional hierarchy. Three major functions are
noted on the first level of the hierarchy.
The subfunctions associated with a major SafeHome
function may be examined by exposing detail vertically in
the hierarchy, as illustrated in Figure 2. Moving downward
along a single path below the function monitor sensors,
partitioning occurs vertically to show increasing levels of
functional detail.
The partitioning approach that we have applied to
SafeHome functions can also be applied to the information
domain and behavioral domain as well. In fact, partitioning of information flow and system behavior will provide
additional insight into system requirements. As the problem is partitioned, interfaces between functions are
derived. Data and control items that move across an interface should be restricted to: inputs required to perform the
stated function and outputs required by other functions or
system elements.
Essential and Implementation Views
An essential view (some people call this the logical view) of
software requirements presents the functions to be accomplished and information to be processed without regard to
implementation details. For example, the essential view of
the SafeHome function read sensor status does not concern
itself with the physical form of the data or the type of sensor that is used. In fact, it could be argued that read status
would be a more appropriate name for this function, since
it disregards details about the input mechanism altogether.
Similarly, an essential data model of the data item phone
number (implies the function dial phone number) can be
represented at this stage without regard to the underlying
data structure (if any) used to implement the data item. By
focusing attention on the essence of the problem at early
stages of requirements analysis, we leave our options open
to specify implementation details during later stages of
requirements specification and software design.
The implementation view (also called the physical
view) of software requirements presents the real world
manifestation of processing functions and information
structures. In some cases, a physical representation is
developed as the first step in software design. However,
most computer-based systems are specified in a manner
that dictates accommodation of certain implementation
details. A SafeHome input device is a perimeter sensor (not
a watchdog, a human guard or a booby trap). The sensor
detects illegal entry by sensing a break in an electronic circuit. The general characteristics of the sensor should be
noted as part of a software requirements specification. The
analyst must recognize the constraints imposed by predefined system elements (the sensor) and consider the implementation view of function and information when such a
view is appropriate.
We have already noted that software requirements
analysis should focus on what the software is to accomplish, rather than on how processing will be implemented.
However, the implementation view should not necessarily
be interpreted as a representation of how. Rather, an implementation model represents the current mode of operation;
that is, the existing or proposed allocation for all system
elements. The essential model (of function or data) is
generic in the sense that realization of function is not
explicitly indicated.
Exercise 5-3,
Applying Analysis Principles
in an OO World
The analysis principles that were just introduced are
applicable to object-oriented thinking. Consider the
basic OO concepts that were introduced in ESE
Module 5-1 and answer the following questions:
1. How does the analysis of the information domain
come into play when we think about objects? What
information domain components do you think we'll
have to define during OO analysis?
5-2.4 ·· Essential Software Engineering
2. What are the functional components of an OO
model?
3. Does behavior have meaning in the context of
OO? Can you think of a special form of behavior that
is specific to OO systems?
4. How does partitioning manifest itself in an OO
model?
5. How do we move from essence to implementation in the context of OO software engineering?
6. Compare your answers with a colleague.
objects may be more difficult to comprehend.
We can begin to identify objects by examining the
problem statement or by performing a grammatical parse
on the processing narrative for the system to be built.
Objects are determined by underlining each noun or noun
clause and entering it in a simple table. Synonyms should
be noted. If an object is required to implement a solution,
then it is part of the solution space; otherwise, if an object is
necessary only to describe a solution, it is part of the problem space. But what should we look for once we've isolated
all of the nouns?
Objects manifest themselves in one of the following
ways. They can be:
 external entities (e.g., other systems, devices, people)
that produce or consume information to be used by a comObject 0riented Analysis
puter-based system;
 things (e.g, reports, displays, letters, signals) that are
part of the information domain for the problem;
Object-Oriented Analysis (OOA) has one dominant
objective: to define all classes that are relevant to the  occurrences or events (e.g., a property transfer or the
completion of a series of robot movements) that occur
problem to be solved. To accomplish this objective a
within
the context of system operation;
number of tasks must occur:
 roles (e.g., manager, engineer, salesperson) played by
people who interact with the system;
1. Classes must be identified (i.e., attributes and
 organizational units (e.g., division, group, team) that are
methods are defined).
relevant to an application;
2. A class hierarchy must be specified.
 places (e.g., manufacturing floor or loading dock) that
3. Object-to-object relationships (object connecestablish the context of the problem and the overall functions) should be represented.
4. Tasks 1 through 3 are reapplied iteratively until the tion of the system;
model is complete.
 structures (e.g., sensors, four-wheeled vehicles or computers) that define a class of objects or in the extreme, relatLike all analysis approaches, OOA is a modeling activ- ed classes of objects.
ity. Therefore, to accomplish the tasks noted above,
It is also important to note what objects are not. An
we'll need a notation and a set of heuristics for applyobject
is not a module or procedure in the conventional
ing the notation.
sense. For example, if the developers of software for a medical imaging system defined an object with the name image
inversion, they would be making a subtle mistake. The
image obtained from the software could, of course, be an
The following excerpt has been adapted from
object (it is a thing that is part of the information domain).
Software Engineering: A Practitioner's Approach and Inversion of the image is an operation that is applied to the
presents a discussion of a popular OOA notation.
object. It is likely that inversion would be defined as an
All analysis methods make use of the object definition pre- operation for the object image, but it would not be defined
sented in [ESE Module 5-1], but each introduces its own
as a separate object to connote "image inversion."
notation, heuristics and philosophy. To illustrate the OOA
To illustrate how objects might be defined during the
modeling approach, the notation adapted from Coad and
early stages of analysis, we return to the SafeHome security
Yourdon [1] will be used.
system example discussed in other ESE Modules. We perThe OOA approach proposed by Coad and Yourdon
formed a grammatical parse on a processing narrative for
consists of five steps: (1) identifying objects; (2) identifying the SafeHome system. The processing narrative is reprostructures; (3) defining subjects; (4) defining attributes and duced below:
instance connections, and (5) defining operations and message connections. An overview of the mechanics and nota- SafeHome software enables the homeowner to configure
tion for steps 1 through 5 is presented in the paragraphs
the security system when it is installed, monitors all senthat follow.
sors connected to the security system, and interacts with
the homeowner through a keypad and function keys contained in the SafeHome control panel shown in Figure 6.6.
Identifying Objects
During installation, the SafeHome control panel is
used
to program and configure the system. Each sensor is
If you look around a room, there is a set of physical objects
assigned
a number and type, a master password is prothat can be easily identified, classified and defined (in
terms of attributes and operations). But when you look
around the problem space of a software application, the
Readings
Object-Oriented Analysis .. 5-2.5
grammed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event
occurs.
When a sensor event is sensed by the software, it rings
an audible alarm attached to the system. After a delay time
that is specified by the homeowner during system configuration activities, the software dials a telephone number of a
monitoring service, provides information about the location, reporting and the nature of the event that has been
detected. The number will be re-dialed every 20 seconds
until telephone connection is obtained.
All interaction with SafeHome is managed by a userinteraction subsystem that reads input provided through
the keypad and function keys, displays prompting messages on the LCD display, displays system status information on the LCD display. Keyboard interaction takes the
following form ...
Extracting the nouns, we can propose a number of potential objects:
Potential Obiect/Class
homeowner
sensor
control panel
installation
security system
number, type
master password
telephone number
sensor event
audible alarm
monitoring service
General Classification
role or external entity
external entity
external entity
occurrence
thing
not objects, attributes
thing
thing
occurrence
external entity
organizational unit or
external entity
The above list would be continued until all nouns in the
processing narrative have been considered. Note that we
call each entry in the list a potential object. We must consider each further before a final decision is made.
Coad and Yourdon [1] suggest six selection characteristics that should be used as an analyst considers each
potential object for inclusion in the analysis model:
1. retained information--the potential object will be useful
during analysis only if information about it must be
remembered so that the system can function
2. needed seruices--the potential object must have a set of
identifiable operations that can change the value of its
attributes in some way;
3. multiple attributes-during requirement analysis, the
focus should be on "major" information; an object with a
single attribute may, in fact, be useful during design, but is
probably better represented as an attribute of another
object during the analysis activity;
4. common attributes-a set of attributes can be defined
for the potential object and these attributes apply to all
occurrences of the object;
5. common operations--a set of operations can be defined
for the potential object and these operations apply to all
occurrences of the objed;
6. essential requirements-external entities that appear in
the problem space and produce or consume information
that is essential to the operation of any solution for the system will almost always be defined as objects in the requirements model.
To be considered a legitimate object for inclusion in
the requirements model, a potential object should satisfy
all (or almost ail) of the above characteristics. The decision
for inclusion of potential objects in the analysis model is
somewhat subjective, and later evaluation may cause an
object to be discarded or reinstated. However, the first step
of OOA must be a definition of objects and/or classes, and
decisions (even subjective ones) must be made. With this in
mind, we apply the selection characteristics to the list of
potential SafeHome objects:
Potential Object/Class, Status
homeowner, rejected: 1, 2 fail even though 6 applies
sensor, accepted: all apply
control panel, accepted: all apply
installation, rejected
system (security system), accepted: all apply
number, type, rejected: 3 fails, attributes of sensor
master password, rejected: 3 fails
telephone number, rejected: 3 fails
sensor event, accepted: all apply
audible alarm, accepted: 2, 3, 4, 5, 6 apply
monitoring service, rejected: 1, 2 fail even though 6 applies
It should be noted that: (1) the above list is not all-inclusive, additional objects would have to be added to com
plete the model; (2) some of the rejected potential objects
will become attributes for those objects that were accepted
(e.g., number and type are attributes of sensor, and master
password and telephone number may become attributes
of system); (3) different statements of the problem might
cause different accept or reject decisions to be made (e.g., if
each homeowner had his or her own password or was
identified by voice print, the homeowner object would satisfy characteristics 1 and 2 and would have been accepted).
Classification and Assembly Structures
Once objects have been identified, the analyst begins to
focus on classification structure. Each object is "considered
as a generalization, then as a specialization." [1] That is, the
instances of an object are defined and named. To illustrate,
consider the sensor object defined for SafeHome and
shown in Figure 1. In other cases, an object represented in
the initial model might actually be composed of a number
of component parts that could themselves be defined as
objects. Structures of this type are called assembly structures,
and are defined using the notation represented in Figure 2.
5-2.6 ·· Essential Software Engineering
The triangle implies an assembly relationship. It should be
noted that the connecting lines may be augmented with
additional symbols (not shown) that are adapted from the
entity-relationship modeling notation discussed later in
this chapter.
that the control panel for SafeHome is considerably more
complex than the one implied by Figure 2, containing multiple display areas, a sophisticated key arrangement and
other features. It might be modeled as an assembly structure that has a number of different levels. For example, display area might be represented by a level that contains
LCD display, icons, and messages objects, each with its
own attribute and operations.
If the overall requirements model contains dozens of
these structures (SafeHome would not), it would be difficult to absorb the entire representation at one time. For this
reason we define a subject reference as shown in the Figure
3. The entire structure can be referenced by a single icon
(the rectangle). Subject references are generally created for
any structure that has more than five or six objects.
At the most abstract level, the OOA model would conStructure representation provides the analyst with a
tain
only
subject references such as those illustrated at the
means for partitioning the requirements model. The expantop
of
Figure
3. Each of the references would be expanded
sion of each object provides needed detail for review and
into a structure. [In the context of the ESE Module 5-3, subfor subsequent design.
jects are analogous to the subsystems discussed as part of
system design.]
Defining Subjects
Instance Connections and Message Paths
A real OOA model may have hundreds of classes and
objects and dozens of structures. For this reason, it is necessary to define some concise representation that is a digest Objects do not exist in a vacuum. An analyst can define
relationships for each object in the model. An instance conof the object and structure models described above.
A subject is nothing more than a reference or pointer to nection is a modeling notation that defines a specific relationship between instances of an class.
more detail in the analysis model. For example, assume
Instance connections are represented using a notation
that is quite similar to the entity-relationship diagram [see
Object-Oriented Analysis .. 5-2.7
ESE Module 3-3, part 1 for details]. Simple lines between
objects indicate that some important relationship does
exist. For example, sensors can generate a sensor event and
sensor events must be recognized by the system. Once the
lines have been established, two additional steps are
required:
1. identify what each connection means, i.e., what the
relationship between the objects is
2. define the cardinality of the relationship, i.e., whether
a single (1 : 1) connection exists or a multiple connection (1
: many) exists.
By representing instance connections, the analyst adds
still another dimension to the OOA model. Not only are the
relationships between objects identified, but all important
message paths are defined. In our discussion of Figure 3,
we made reference to the arrows that connected subject
symbols. For the message paths (sometimes referred to as
message connections) each arrow implies the interchange of
messages among objects in the model. As we have already
noted, messages will move along each instance connection
path; therefore, message connections are derived directly
from instance connections.
Like the structured analysis diagrams presented in
ESE Modules 3-3, graphical representation forms the basis
for the OOA model and provides an excellent foundation
for the creation of a Software Requirements Specification.
Each object represented graphically must also be described
using a text-oriented format.
OOA and Prototyping
It is important to note that the use of OOA can lead to
extremely effective prototyping and evolutionary software
engineering techniques. The objects that are specified and
ultimately implemented for a current project can be catalogued in a library. Classes are inherently reusable and
over time, the library of reusable classes will grow. When
OOA is applied to new projects, the analyst can work to
specify the system using existing (implemented) objects
contained in the object library, rather than inventing new
ones (this practice is commonplace in hardware design;
system engineers specify existing ICs, rather than requiring
custom design). For example, the sensor and sensor event
objects described for SafeHome could be used without
change in a variety of process control and monitoring
applications. Similarly, the control panel object could have
broad application in other products.
By using existing objects during analysis, specification
time is reduced substantially, and a rapid prototype of the
specified system can be created and reviewed by the customer. Even more important, the prototype can evolve into
a working product or system because the building blocks
that created it (the objects) have already been proven in
practice.
[1] Coad, P. and Yourdon E (1991), Object-Oriented
Analysis, Prentice-Hall, 2nd edition
Exercise 5-4,
Creating an Analysis Model
Using the notation described in the preceding video
segment and the reading, attempt to develop a rudimentary OOA model for a problem that you're currently working on. Perform the following tasks:
1. Write a statement of scope for the problem.
2. Use the grammatical parse to isolate potential
objects.
3. Using the rules described in the reading, isolate
first iteration objects.
4. Define attributes and methods (possibly by refining your written statement of scope and reapplying
the grammatical parse).
5. Using the notation described in this ESE module,
draw a picture of each class/object.
6. Build a class hierarchy.
7. Build an assembly structure(s) as required.
8. Develop subject references and instance connections to complete your rudimentary model.
9. Discuss your answers with a colleague.
5-2.8 ·· Essential Software Engineering
Post-Test Module 5-2
7. The class at the top of the class hierarchy is
called a:
a. main class
This post-test has been designed to help you assess
b. lead class
the degree to which you've absorbed the information
c. superclass
presented in this ESE Module.
d. prime object
Object-Oriented Analysis
1. An analysis fundamental is partitioning. In OOA,
this is best characterized by:
a. instance connections
b. operations
c. the class hierarchy
d. messages
e. none of the above
2. The difference between domain analysis and
requirements analysis is:
a. one focuses on a broad class of problems
while the other focuses on an application
b. one focuses on the domain of change
c. one focuses on the behavioral domain while
the other focuses on the functional domain
d. none of the above
3. For an OOA method to be complete, it should
encompass:
a. a notation
b. a set of heuristics
c. a modeling process
d. all of the above
e. none of the above
4. In order to define candidate classes, the analyst
should:
a. use intuition
b. list all objects in the class library
c. select nouns from a grammatical parse
d. select every verb in a grammatical parse
5. Once classes are established, the next thing you
should do is:
a. begin design
b. establish relationships and a class hierarchy
c. identify attributes and methods
d. determine object behavior
e. none of the above
6. Modeling class relationships (instance connections) enable you to:
a. define aggregate objects
b. understand attributes
c. define methods
d. none of the above
8. Subclasses are created when :
a. an attribute or method is not applicable to all
instances of a class
b. a smaller class is desired
c. an exception occurs
d. an assembly structure must be built
9. A trigger is used when applying which analysis
principle:
a. information domain modeling
b. functional modeling
c. behavioral modeling
d. partitioning
10. An assembly structure is used to:
a. represent how messages are assembled
b. represent how various objects are combined
c. represent how attributes are assembled to
create an object definition
d. assemble an object-oriented application
11. Relationship modeling represents the system in a
way that enables the analyst to understand how:
a. a relational database might be used to
implement the system
b. objects pass messages among themselves
c. objects are constructed
d. objects behave
12. The state of an object can be determined by
examining
a. its operations
b. its attributes
c. its triggers
d. none of the above
Copyright 1995 R.S. Pressman & Associates, Inc.
No part of this material may be electronically copied,
transmitted, or posted without the express written
permission of R.S. Pressman & Associates, Inc.
These materials have been posted on the Local Web
Server of the Department of Computer Science with
permission of R.S. Pressman & Associates, Inc. and are
for use only by students registered for DCS/235 at
Queen Mary and Westfield College.