Object Oriented Analysis/OOA

Learning Outcomes

• In this activity, you should be able to define and

understand
– What object oriented analysis is
– The analysis activities
– Analysis management

04/17/2025 KMU - OOA 2

 Introduction

• The first step in finding an appropriate solution to a given

problem is to understand the problem and its domain.
• Analysis capture a complete, unambiguous and consistent
picture of requirements of system and what the system
must do to satisfy the user’s requirements and needs.
– This is accomplished by constructing several models that
concentrate on describing what the system does rather that how it
does it
• Analysis is a process of transforming problem definition
from fuzzy set of facts and myths into coherent statement
of system’s requirements

04/17/2025 KMU - OOA 3

Cont’d
• Analysis results in a model of the system that aims to be
correct, complete, consistent, and verifiable.
• Developers formalize the system specification produced
during requirements elicitation and examine in more detail
boundary conditions and exceptional cases.
• Developers correct and clarify the system specification if
any errors or ambiguities are found.
• The client and the user are usually involved in this activity,
especially when the system specification needs to be
changed and when additional information needs to be
gathered.

KMU - OOA 4
04/17/2025
Cont’d
• Formalization helps identify areas of ambiguity as well as
inconsistencies and omissions in a system specification.
• Once developers identify problems with the specification,
they address them by eliciting more information from the
users and the client.
• For extracting information about a system analyst uses
– Examination of existing system documentation
– Interviews
– Questionnaire
– Observation
– Literature review is also used sometimes. Analyst is concerned with
uses of system, identifying objects and inheritance
• Analysis involve great deal of interaction with people who
will affected by the system
04/17/2025 KMU - OOA 5
Cont’d
• In analysis, we seek to model the world by discovering
the classes and objects that form the vocabulary of the
problem domain
• In design, we invent the abstractions and mechanisms
that provide the behavior that this model requires

04/17/2025 KMU - OOA 6

Object Oriented Analysis

• An object oriented environment allows the same set of

models to be used for analysis, design and
implementation.
• The analyst is concerned with the uses of the system,
identifying the objects and inheritance and thinks about
the events that change the state of objects.
• The designer adds detail to this model, perhaps designing
screens, user interaction and database access
• In object-oriented analysis, developers build a model
describing the application domain.
– Finding and describing the concepts in the problem domain
– Emphasizes an investigation of the problem, requirements and
formalize them.
04/17/2025 KMU - OOA 7
Cont’d

• Object-oriented analysis 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.
• The goal of OOA is to understand the domain of the problem
and the system’s responsibilities by understanding how the
users use or will use the system.
• Developers use the analysis model, together with
nonfunctional requirements, to prepare for the architecture of
the system developed during high-level design (i.e. system
Design)
04/17/2025 KMU - OOA 8
How OOA & OOD related

• OOA
– Emphasizes on finding and describing the objects or
concepts in the problem domain
– Basically, the products of object oriented analysis serve as
the models from which we may start an object-oriented
design
• OOD
– Emphasizes a conceptual solution that fulfills the
requirements and define s/w objects, their responsibilities
and how they collaborate to fulfill the requirement.
– The products of object-oriented design can then be used as
blueprints for completely implementing a system using
object-oriented programming methods.
04/17/2025 KMU - OOA 9
Cont’d

• Analysis • Design
– Focuses on understanding • Focuses on
the problem understanding the
– System model solution
– Small model of domain • System structure
concept • A large model of
system dynamic and
static view

Requirement Analysis -> Use case model

OOA- > Analysis Model(domain Model)
OOD-> Design Model

04/17/2025 KMU - OOA 10

Overview of Analysis
• Analysis focuses on producing a model of the system, called
the analysis model, which is correct, complete, consistent,
and verifiable.
– Translating a system specification into a formal or semiformal model
forces developers to identify and resolve difficult issues early in the
development
• Analysis is an essential bridge between requirements capture
and design, leading us from a clear statement of what the
system must provide to a clear understanding of the objects
that we’ll be dealing with
• Once we understand the objects that we must deal with, we
stand a much better chance of producing an elegant solution.
• Analysis is different from requirements elicitation in that
developers focus on structuring and formalizing the
requirements elicited from users
04/17/2025 KMU - OOA 11
• There are two inputs to analysis:
– The business requirements model contains descriptions of the
manual and automated workflows of our business context,
described using business-oriented versions of actors, use cases,
objects, the glossary and, optionally, communication diagrams
and activity diagrams.
– The system requirements model contains an external view of
the system, described as system-oriented versions of actors, use
cases and use case diagrams, user
interface sketches, an enhanced glossary and nonfunctional
requirements.
• These inputs must be transformed into a model of the objects
that will be processed by the proposed system, along with
their attributes and relationships

04/17/2025 KMU - OOA 12

 Figure: Products of requirements elicitation and analysis

04/17/2025 KMU - OOA 13

Why analysis difficult?
• Analysis is creative activity that involves understanding
the problem, its associated constraints, methods of
overcoming those constraints.
• Three most common sources of requirement difficulties:-
– Fuzzy descriptions
– Incomplete Requirements
– Unnecessary features
• Analysis is a difficult activity. You must understand the
problem in some application domain and then define a
solution that can be implemented with software.
– solution, Experience is the best teacher

04/17/2025 KMU - OOA 14

Analysis Model
• The analysis model may not be understandable to the
users and the client, it helps developers verify the system
specification produced during requirements elicitation.
• The analysis model is composed of three individual
models:
– The functional model, represented by use cases and scenarios,
– The analysis object model, represented by class and object
diagrams, and
– The dynamic model, represented by statechart and sequence
diagrams
• This leads to a more precise and complete specification as
details are added to the analysis model.

04/17/2025 KMU - OOA 15

Analysis Concepts
• The main analysis concepts used in this activity :
– Analysis Object Models and Dynamic Models
– Entity, Boundary, and Control Objects

04/17/2025 KMU - OOA 16

Analysis Object models and Dynamic models
• The analysis object model is a part of the analysis model and
focuses on the individual concepts that are manipulated by the
system, their properties and their relationships.
• The analysis object model, depicted with UML class diagrams,
includes classes, attributes, and operations. The analysis object
model is a visual dictionary of the main concepts visible to the user.
• The dynamic model focuses on the behavior of the system.
• The dynamic model is depicted with sequence diagrams and with
state machines.
• Sequence diagrams represent the interactions among a set of objects
during a single use case. State machines represent the behavior of a
single object (or a group of very tightly coupled objects).
• The dynamic model serves to assign responsibilities to individual
classes and, in the process, to identify new classes, associations, and
attributes to be added to the analysis object model.
04/17/2025 KMU - OOA 17
Entity, Boundary, and Control Objects
• The analysis object model consists of entity, boundary,
and control objects
– Entity objects represent the persistent information
tracked by the system.
• Application domain objects, “Business objects”
– Boundary objects represent the interactions
between the actors and the system (interface
objects).
– Control objects represent the tasks that are
performed by the user and supported by the system.
• Represent the control tasks performed by the system

04/17/2025 KMU - OOA 18

Example: Watch Objects

Year Button
ChangeDate

Month
LCDDisplay

Day

Entity Objects Control Objects Interface Objects

04/17/2025 KMU - OOA 19

Analysis Activities: From Use Cases to Objects

• Here, we describe the activities that transform the use cases and
scenarios produced during requirements elicitation into an analysis model.

• Analysis activities include:

– identifying entity objects
– identifying boundary objects
– identifying control objects
– mapping use cases to objects with sequence diagram
– identifying associations among objects
– identifying object attributes
– modeling behavior with state charts
– modeling generalization relationships
– reviewing the analysis model

04/17/2025 KMU - OOA 20

For instance, Analysis Activities: From Use Cases
to Objects

An example of a UML use case diagram: Incident initiation in an

accident management system.

04/17/2025 KMU - OOA 21

 Identifying Entity Objects
• Participating objects form the basis of the analysis model.
• As described in Requirements Elicitation, participating
objects are found by examining each use case and
identifying candidate objects.
• Natural language analysis is an intuitive set of heuristics
for identifying objects, attributes, and associations from a
system specification.
• Abbott’s heuristics maps parts of speech (e.g., nouns,
Doing verbs, being verbs, adjectives) to model
components (e.g., objects, operations, inheritance
relationships, Attributes).

04/17/2025 KMU - OOA 22

Identifying Boundary Objects
• Boundary objects represent the system interface with the
actors. In each use case, each actor interacts with at least one
boundary object.
• The boundary object collects the information from the actor and
translates it into form that can be used by both entity and
control objects.
• Boundary object model user interface at coarse level. The do
not describe in detail the visual aspects of the user interface.
For example, boundary objects such as “menu item” or “scroll
bar” are too detailed.
• First, developers can discuss user interface details more easily
with sketches and mock-ups.
• Second, the design of the user interface will continue to evolve
as a consequence of usability tests, even after the functional
specification of the system becomes stable
04/17/2025 KMU - OOA 23
Identifying Control Objects
• It is a kind of algorithm or code that controls the interaction
between boundary and entity objects
• Control objects are responsible for coordinating boundary and
entity objects.
• Control objects usually do not have a concrete counterpart in the
real world.
• There is often a close relationship between a use case and a
control object.
• A control object is usually created at the beginning of a use case
and ceases to exist at its end.
• It is responsible for collecting information from the boundary
objects and dispatching it to entity objects.
• For example, control objects describe the behavior associated
with the sequencing of forms, undo and history queues, and
dispatching information in a distributed system.
04/17/2025 KMU - OOA 24
Mapping use cases to objects with sequence
diagrams/Modeling Interactions Between Objects: Sequence
Diagrams
• A sequence diagram ties use cases with objects. It shows how the
behavior of a use case (or scenario) is distributed among its
participating objects.
• Sequence diagrams are usually not a good medium for
communication with the user as use case are, since sequence
diagrams require more background about the notation .
• They represent another shift in perspective and allow the developers
to find missing objects or grey areas in the system specification.
• In general, the second column of a sequence diagram represents the
boundary object with which the actor interacts to initiate the use case
• The third column is a control object that manages the rest of the use
case
• From then on, the control object creates other boundary objects and
may interact with other control objects as well

04/17/2025 KMU - OOA 25

 Sequence diagram for the ReportEmergency use case

04/17/2025 KMU - OOA 26

 Sequence diagram for the ReportEmergency use case
continued…
04/17/2025 KMU - OOA 27
 Sequence diagram for the ReportEmergency use case continued…

04/17/2025 KMU - OOA 28

 Identifying Associations
• sequence diagrams allow developers to represent
interactions among objects over time where as class
diagrams allow developers to describe the
interdependencies of objects.
• An association shows a relationship between two or
more classes.
• For example, a FieldOfficer writes an EmergencyReport

04/17/2025 KMU - OOA 29

• Identifying associations has two advantages. First, it clarifies
the analysis model by making relationships between objects
explicit (e.g., an EmergencyReport can be created by a
FieldOfficer or a Dispatcher).
• Second, it enables the developer to discover boundary cases
associated with links.
• Boundary cases are exceptions that need to be clarified in the
model.
• For example, it is intuitive to assume that most
EmergencyReports are written by one FieldOfficer. However,
should the system support EmergencyReports written by more
than one? Should the system allow for anonymous
EmergencyReports?
• Those questions should be investigated during analysis by
discussing them with the client or with end users .
04/17/2025 KMU - OOA 30
• Associations properties:
– A name, to describe the association between the two
classes(e.g., Writes). Association names are optional
and need not be unique globally.
– A role at each end, identifying the function of each
class with respect to the associations (e.g., author is
the role played by FieldOfficer in the Writes
association).
– A multiplicity at each end, identifying the possible
number of instances (e.g., * indicates a FieldOfficer
may write zero or more EmergencyReports, whereas 1
indicates that each EmergencyReport has exactly one
FieldOfficer as author.

04/17/2025 KMU - OOA 31

Identifying Aggregates
• Aggregates are special types of associations denoting a
whole-part relationship.
• Fro example, a FireStation consists of a number of
FireFighters, FireEngines, Ambulances, and a LeadCar.
• A Region is composed of a number of zones that are in
turn composed of a number of weredas.
• Aggregation associations are used in the analysis model
to denote whole-part concepts. It adds information to the
analysis model about how containment concepts in the
application domain can be organized in a hierarchy.
• Aggregations are often used in the user interface to help
the user browse through many instances

04/17/2025 KMU - OOA 32

 Aggregation

Composition Aggregation

If you are not sure that the association you are describing is a whole–part
concept, it is better to model it as a one-to-many association, and revisit it later
when you have a better understanding of the application domain

04/17/2025 KMU - OOA 33

 Identifying Attributes
• Attributes are properties of individual objects. For example, an
EmergencyReport has an emergency type, a location, and a
description property.
• These are entered by a FieldOfficer when he/she reports an
emergency and are subsequently tracked by the system.
• When identifying properties of objects, only the attributes
relevant to the system should be considered.
• For example, each FieldOfficer has a social security number
that is not relevant to the emergency information system.
• Instead, FieldOfficers are identified by badge number,
represented by the badgeNumber property.

04/17/2025 KMU - OOA 34

• Heuristics for identifying attributes
– Examine possessive phrases.
– Represent stored state as attributes of entity object.
– Describe each attribute.
– Do not represent an attribute as an object, use an association
instead
– Do not waste time describing fine details before the object
structure is stable.

04/17/2025 KMU - OOA 35

Reviewing the analysis model
• The analysis model is built incrementally and iteratively.
The analysis model is seldom correct or even complete
on the first pass.
• Several iterations with the client and the user are
necessary before the analysis model converges toward a
correct specification usable by the developers for
proceeding to design and implementation.
• For example, an omission discovered during analysis will
lead to adding or extending a use case in the system
specification, which may lead to eliciting more
information from the user.

04/17/2025 KMU - OOA 36

• Once the analysis model becomes stable (i.e., when the
number of changes to the model are minimal and the
scope of the changes localized), the analysis model is
reviewed, first by the developers (i.e., internal reviews),
then jointly by the developers and the client.
• The goal of the review is to make sure that the system
specification is correct, complete, consistent, and
realistic.

04/17/2025 KMU - OOA 37

Managing Analysis
• The primary challenge in managing the requirements is to
maintain consistency while using so many resources.
• In the end, the requirements analysis document should
describe a single coherent system understandable to a
single person
• Documenting Analysis
• The requirements elicitation and analysis activities are
documented in the Requirements Analysis Document
(RAD).
• During analysis, we revise these sections as ambiguities
and new functionality is discovered.
• The main effort, however, focuses on writing the sections
documenting the analysis object model (3.5.3–3.5.4).
04/17/2025 KMU - OOA 38
 Requirements Analysis Document Template
1. Introduction
2. Current system
3. Proposed system
3.1 Overview
3.2 Functional requirements
3.3 Nonfunctional requirements
3.4 Constraints (“Pseudo requirements”)
3.5 System models
3.5.1 Scenarios
3.5.2 Use case model
3.5.3 Object model
3.5.3.1 Data dictionary
3.5.3.2 Class diagrams
3.5.4 Dynamic models
3.5.5 User interface
4. Glossary

04/17/2025 KMU - OOA 39

 Summary: Analysis
• 1. What are the transformations? Functional Modeling
– Create scenarios and use case diagrams
• Talk to client, observe, get historical records, do thought
experiments
2. What is the structure of the system? Object Modeling
Create class diagrams
Identify objects.
What are the associations between them? What is their
multiplicity?
What are the attributes of the objects?
What operations are defined on the objects?
3. What is its behavior? Dynamic Modeling
Create sequence diagrams
Identify senders and receivers
Show sequence of events exchanged between objects. Identify
event dependencies and event concurrency.
Create state diagrams
Only for the dynamically interesting objects.
04/17/2025 KMU - OOA 40
 Do Analysis
1. Analyze the problem statement
– Identify functional requirements
– Identify nonfunctional requirements
2. Build the functional model
– Develop use cases to illustrate functionality requirements
3. Build the dynamic model:
– Develop sequence diagrams to illustrate the interaction
between objects
– Develop state diagrams for objects with interesting behavior
4. Build the object model:
– Develop class diagrams showing the structure of the system

04/17/2025 KMU - OOA 41